On Tue, 2006-11-28 at 03:54 -0700, Andreas Dilger wrote: > > > > >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()? I half agree with allowing for a configurable stat call. But when it comes to standards and expecting everybody to adhere them a well defined list required and optional fields seems necessary. Otherwise every app will simply start asking for various fields they *think* is important, without much regard for what might be and expensive stat to obtain cluster wide and which ones are cheap. By clearly defining the list and standardizing that list the app programmer and the kernel programmer know what is expected. The mask idea sounds like a good way to implement it, but at the same time create standards defined masks for things like color ls. > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Russell Cattelan <cattelan@xxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
