[lsb-discuss] statfs specification addition: review

Robert Schweikert robert.schweikert at abaqus.com
Fri Dec 22 05:28:18 PST 2006

On Thu, 2006-12-21 at 19:16 -0500, Theodore Tso wrote:

> Sure, portable applications shouldn't use depend on
> filesystem-specific features or interfaces.  

My guess is you will not find many applications which use file system
specific interfaces. As you mention, this would be a portability killer.
With the exception of a few companies no one will get away with telling
their customers what file system to use.

> 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. 

Agreed, and I think you will find this to be true in 98% of

>  (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, 

I do not share this concern. While this may be an issue in the most
general case I think most applications will be interested in a very
special case; is the file system local or not, i.e. is the file I am
dealing with on an NFS mounted file system. When one deals with large
data sets telling the user to copy the data to a local machine to get
decent data access performance is just not an option, thus the
application has to deal with this in a different way.

> 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.

I don't think timing should be an issue here. With statfs making its way
into the LSB it will be about 6 years before it will disappear from the
LSB (the interface starts out as being marked deprecated). This should
provide sufficient time for kernel and glibc development to come up with
a way, either (f)pathconf or statvfs to provide the information needed.

> 						- Ted
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com)                 LINUX
Phone : 401-276-7190
FAX : 401-276-4408

More information about the lsb-discuss mailing list