On Dec 05, 2006 15:55 -0800, Ulrich Drepper wrote: > I don't think an accuracy flag is useful at all. Programs don't want to > use fuzzy information. If you want a fast 'ls -l' then add a mode which > doesn't print the fields which are not provided. Don't provide outdated > information. Similarly for other programs. Does this mean you are against the statlite() API entirely, or only against the document's use of the flag as a vague "accuracy" value instead of a hard "valid" value? > Christoph Hellwig wrote: > >I think having a stat lite variant is pretty much consensus, we just need > >to fine tune the actual API - and of course get a reference implementation. > >So if you want to get this going try to implement it based on > >http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115487991724607&w=2. > >Bonus points for actually making use of the flags in some filesystems. > > I don't like that approach. The flag parameter should be exclusively an > output parameter. By default the kernel should fill in all the fields > it has access to. If access is not easily possible then set the bit and > clear the field. There are of course certain fields which always should > be added. In the proposed man page these are already identified (i.e., > those before the st_litemask member). IMHO, if the application doesn't need a particular field (e.g. "ls -i" doesn't need size, "ls -s" doesn't need the inode number, etc) why should these be filled in if they are not easily accessible? As for what is easily accessible, that needs to be determined by the filesystem itself. It is of course fine if the filesystem fills in values that it has at hand, even if they are not requested, but it shouldn't have to do extra work to fill in values that will not be needed. "ls --color" and "ls -F" are prime examples. It does stat on files only to get the file mode (the file type is already part of many dirent structs). But a clustered filesystem may need to do a lot of work to also get the file size, because it has no way of knowing which stat() fields are needed. > And one last point: I haven't seen any discussion why readdirplus should > do the equivalent of stat and there is no 'statlite' variant. Are all > places for readdir is used non-critical for performance or depend on > accurate information? That was previously suggested by me already. IMHO, there should ONLY be a statlite variant of readdirplus(), and I think most people agree with that part of it (though there is contention on whether readdirplus() is needed at all). 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
