On Mar 27, 2017, at 1:04 PM, Jeff Layton <jlayton@poochiereds.net> wrote:
> 
> On Mon, 2017-03-27 at 09:46 -0700, Christoph Hellwig wrote:
>> On Mon, Mar 27, 2017 at 05:25:26PM +0100, David Howells wrote:
>>> That means a filesystem can't simply return non-basic data unconditionally if
>>> possible.  I prefer letting it do so if it doesn't incur any extra I/O
>>> overheads.
>> 
>> This seems like it will lead to userspace expecting certain fields to
>> just be there, and a lot harder to properly verify for tests.  Which btw
>> we all need for these odd behaviors.  If we can't get them any time soon
>> (e.g. before -rc6) I think we'll simply have to revert statx instead of
>> leaving this untested mess in the tree.
> 
> I don't think so.
> 
> I think we just have to clearly document that that will not be the
> case. If they really expect the field to be there, then they need to
> set the bit in the "want" mask -- it's really as simple as that.

It would be my preference to only return attributes which are explicitly
requested (Lustre won't return fields for which the bit is not set), but
there was a request for this behaviour in NFS I recall.

That said, there are also flags for "lazy" attributes for NFS. I wonder if
it is enough to pass AT_STATX_DONT_SYNC and request STATX_SIZE | STATX_CTIME,
or whatever NFS is worried about, and return the client-local version of the
attributes?

I guess the real question is what an application is going to do with fields
that it didn't actually request, and has no way to know if they are valid or
contain garbage?

Cheers, Andreas