[lsb-discuss] statfs specification addition: review

Anthony W. Youngman pixie at thewolery.demon.co.uk
Wed Dec 27 00:40:51 PST 2006

In message <1166794098.27415.170.camel at cheetah.abaqus.com>, Robert 
Schweikert <robert.schweikert at abaqus.com> writes
>>  (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.

Note that I am aware of at least one application (IBM UniVerse) where 
the distinction between local and remote filesystems is CRUCIAL. I'm 
sure others can think of more.

It's a database, it stores each "table" in its own OS-level file, and 
for integrity reasons it *needs* to know whether the files exist 
physically on the local or remote machine. For data integrity reasons, 
by default it will refuse to write to a remote file, instead passing a 
request to the server daemon running on the remote machine.

Anthony W. Youngman <pixie at thewolery.demon.co.uk>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick

More information about the lsb-discuss mailing list