[lsb-discuss] statfs specification addition: review

Theodore Tso tytso at mit.edu
Fri Dec 22 08:09:43 PST 2006


On Fri, Dec 22, 2006 at 08:28:18AM -0500, Robert Schweikert wrote:
> 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.

Define "local or not"?  Is the attribute just one of speed?  On some
systems, especially if you have a really big, really expensive storage
appliance (say, NetApp filer, or a EMC or IBM storage array), a remote
filesystem can actually be *faster* than local hard drives.  And what
about a "local filesystem" that happens to be stored on a very slow
device, either an iSCSI (SCSI over IP) device that is located across a
WAN, or a local filesystem that happens to use a magneto-optical drive?

Or is the attribute one of whether or not another system can modify
the file out from under you?  In that case, you would care whether or
not the filesystem was NFS, or AFS, or GPFS, or OCFS2, or GFS, or
Lustre.... or any number of other remote or cluster filesystems.

Or is it an issue of locking semantics?  Some remote filesystems have
differente locking semantics than local filesystems.  But there, CIFS
is different from NFS which is different from AFS.

Or is it an issue of whether or not data might or might not get
exposed due to lack of encryption on a remote filesystem.  (NFSv3
generally is completely unprotected; AFS has the option for integrity
protection and/or encryption, as does NFSv4)

This is why I am concerned that if an application writer is using
statfs to determine whether or not a filesystem happens to be a NFS
filesystem, that the application writer is probably doing something
seriously non-portable, and ultimatly wrong.  

						- Ted




More information about the lsb-discuss mailing list