On Dec 05, 2006  15:55 -0800, Ulrich Drepper wrote:
quoted text
> 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?

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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html