Re: NFSv4/pNFS possible POSIX I/O API standards

[Anton Altaparmakov <aia21@cam.ac.uk>]

On Tue, 2006-11-28 at 03:54 -0700, Andreas Dilger wrote:
> On Nov 28, 2006  05:54 +0000, Christoph Hellwig wrote:
> > What crack do you guys have been smoking?
> 
> As usual, Christoph is a model of diplomacy :-).
> 
> > On Mon, Nov 27, 2006 at 09:34:05PM -0700, Gary Grider wrote:
> > > >readx/writex - scattergather readwrite - more appropriate and 
> > > >complete than the real time extended read/write
> 
> IMHO, this is a logical extension to readv/writev.  It allows a single
> readx/writex syscall to specify different targets in the file instead of
> needing separate syscalls.  So, for example, a single syscall could be
> given to dump a sparse corefile or a compiled+linked binary, allowing
> the filesystem to optimize the allocations instead of getting essentially
> random IO from several separate syscalls.
> 
> > > >statlite() - asking for stat info without requiring completely 
> > > >accurate info like dates and sizes.  This is good
> > > >for running stat against a file that is open by hundreds of 
> > > >processes which currently forces callbacks
> > > >and the hundreds of processes to flush.
> 
> This is a big win for clustered filesystems.  Some "stat" items are
> a lot more work to gather than others, and if an application (e.g.
> "ls --color" which is default on all distros) doesn't need anything
> except the file mode to print "*" and color an executable green it
> is a waste to gather the remaining ones.
> 
> My objection to the current proposal is that it should be possible
> to _completely_ specify which fields are required and which are not,
> instead of having a split "required" and "optional" section to the
> stat data.  In some implementations, it might be desirable to only
> find the file blocks (e.g. ls -s, du -s) and not the owner, links,
> metadata, so why implement a half-baked version of a "lite" stat()?

Indeed.  It is best to be able to say what the application wants.  Have
a look at the Mac OS X getattrlist() system call (note there is a
setattrlist(), too but that is off topic wrt to the stat() function).

You can see the man page here for example:

http://www.hmug.org/man/2/getattrlist.php

This interface btw also is made such that each file system can define
which attributes it actually supports and a call to getattrlist() can
determine what the current file system supports.  This allows
applications to tune themselves to what the file system supports that
they are running on...

I am not saying you should just copy it.  But in case you were not aware
of it you may want to at least look at it for what others have done in
this area.

Best regards,

	Anton

> Also, why pass the "st_litemask" as a parameter set in the struct
> (which would have to be reset on each call) instead of as a parameter
> to the function (makes the calling convention much clearer)?
> 
> int statlite(const char *fname, struct stat *buf, unsigned long *statflags);
> 
> 
> [ readdirplus not referenced ]
> It would be prudent, IMHO, that if we are proposing statlite() and
> readdirplus() syscalls, that the readdirplus() syscall be implemented
> as a special case of statlite().  It avoids the need for yet another
> version in the future "readdirpluslite()" or whatever...
> 
> Namely readdirplus() takes a "statflags" paremeter (per above) so that
> the dirent_plus data only has to retrieve the required stat data (e.g. ls
> -iR only needs inode number) and not all of it.  Each returned stat
> has a mask of valid fields in it, as e.g. some items might be in cache
> already and can contain more information than others.
> 
> > > >The website is at
> > > >http://www.opengroup.org/platform/hecewg/
> > > >We in the HECIWG would welcome putting forth any NFS related ...
> 
> Strange, group is called HECIWG, website is "hecewg"?
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/