[lsb-discuss] statfs specification addition: review

Theodore Tso tytso at mit.edu
Thu Dec 21 16:16:29 PST 2006


On Thu, Dec 21, 2006 at 02:52:25PM -0800, Camp, TracyX E wrote:
> This is entirely orthoginal and mostly full of red-herring, but an
> interesting historical debate none the less.  ext2 and NTFS both came
> about in 1993 (January and July respectively), but yes ext2 has been
> largely replaced in production with file systems that report a different
> magic (reiserfs for example).  

<offtopic>

Actually, the filesystem which both distributions are shipping by
default is ext3, which does report the same magic number as ext2, and
whose filesystem format is forwards and backwards compatible with
ext2.

See:

http://linux.wordpress.com/2006/09/27/suse-102-ditching-reiserfs-as-it-default-fs

and 

http://linuxmafia.com/faq/Filesystems/reiserfs.html

</offtopic>

> I think my point still stands, that the
> file system is emphimeral over a long-enough time span and applications
> should not be asked to depend upon it specifically.

Sure, portable applications shouldn't use depend on
filesystem-specific features or interfaces.  The main issue for me is
because different people want to use different filesystems, not
because filesystems "go away".  People who like efficient access to
small files (I've always said that if you want to implement a Windows
registry, reiserfs is the filesystem for you :-), may choose a
different filesystem than one which performs well in other performance
domains.  And a portable application should work no matter what
filesystem you've chosen.  (Perhaps not _well_ if you're using a
filesystem which isn't being actively developed and still using the
big kernel lock, but it the application should still work.)

So I do worry that applications that are trying to use statfs() to
find out what filesystem they are on might be doing something very
dubious from a portability perspective, so I definitely agree that if
we can meet their needs by using (f)pathconf, that's definitely a much
better way to go.  That will probably also require kernel/glibc
changes, though, so it's probably not something we could deliver in
time for LSB 4.0, alas.

						- Ted




More information about the lsb-discuss mailing list