[lsb-discuss] statfs specification addition: review

Robert Schweikert robert.schweikert at abaqus.com
Fri Dec 22 09:03:45 PST 2006

On Fri, 2006-12-22 at 11:09 -0500, Theodore Tso wrote:

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

At this point I feel I can only speak for our application. Thus if other
ISVs are reading this feel free to jump in. For us the need to know
whether a file is on an NFS file system or not is two fold. In most
cases there is a relatively slow network between a network storage
device and a desktop machine. Users accessing large data sets stored on
an NFS file system do however expect similar or same performance when
manipulating the data as compared to storage on a local hard drive SATA
or SCSI. We have to deal with this some how and thus we have to know
whether or not the file is on an NFS mount.

Secondly yes, file locking and the file changing do play somewhat of a
role. However, in our case we always assume that the file can change
while the data is being accessed (NFS or not). More often than not users
will access data in a given file while more data is being generated and
added to the file. But again due to performance we want to know if data
needs to be pulled over a network or not.

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

For the general case I certainly understand and share your concerns.
Again I cannot speak for the ISV group here, only for our application.
We have a very specific use case, this case is portable across all UNIX
variants and across Linux distributions. For this case we need to know
whether or not a file is on an NFS mount or not. The NFS or not
information is currently only in statfs.

Yes, as this becomes part of the LSB the general case has to be
addressed somehow, but maybe we don't have to bite off the whole chunk
at once. Address the issues which can be addressed in a reasonable time
frame with a reasonable amount of effort. Trow it out into the world and
see what happens. If we are lucky the initial go around might cover 80%
of all use cases which makes the discussion for the remaining 20% easier
as it will be more targeted and solution oriented.

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