On Tue, 2017-03-28 at 13:39 -0600, Andreas Dilger wrote: > On Mar 27, 2017, at 1:04 PM, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> 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? > You certainly do have a way to know if they're valid. You can check the stx_mask. Basically, if you request something, you're guaranteed to get it, or an error. If you don't request it, you might get it but you had better check the stx_mask before assuming that you did. TBQH though, I don't _really_ expect userland to use this that often. The main reason I'm arguing for this is for simplicity of the in-kernel implementations. Having to check each bit in the mask before filling out its field is cumbersome. It's much simpler to fill out the kstat struct with what you have and set the stx_mask unconditionally. It's also not 100% clear to me how the unrequested fields would be set if we don't allow this. zeroing them out seems like the obvious thing to do, but that doesn't really provide any guarantee that someone won't try to interpret it as valid. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
