Re: [PATCH] nfsd: special case truncates some more

[Jeff Layton <jlayton@poochiereds.net>]

On Mon, 2017-01-23 at 17:05 +0100, Christoph Hellwig wrote:
> On Mon, Jan 23, 2017 at 10:52:09AM -0500, Jeff Layton wrote:
> > To be clear, the client is requesting to set the mtime to current server
> > time and not to a specific mtime, right?
> 
> Yes.  And I think it's mostly the Linux client being lazy - ATTR_MTIME
> is what it gets from the VFS for a truncate operation (but not ftrunate,
> so we probably won't see it on the wire in that case, but I need to verify
> that first).  Yet another reason for ->truncate :)
> 

Heh, ok. Makes sense.

> > I don't see where vfs_truncate will handle the times though. do_truncate
> > will, but you have to pass in a non-zero time_attrs and vfs_truncate
> > always sets that to 0.
> 
> This is the magic of the Linux VFS interface.  For a ATTR_SIZE operation
> the file system is expected to update mtime and ctime if the size changes
> even if ATTR_MTIME and ATTR_CTIME are not set.  See the comments
> in xfs_vn_setattr_size, which I wrote many years ago when I tripped
> over this interesting calling convention.
> 

Ick.

> > If we did want to do this, it seems like it might be better to just add
> > a new time_attrs arg to vfs_truncate that gets passed to do_truncate.
> > Most callers would set it to zero, but nfsd could set it to:
> > 
> >     iap->ia_valid & (ATTR_MTIME|ATTR_CTIME)
> > 
> > Would that work?
> 
> I'd hate it.  I'd rather spent my time on a real truncate operation
> which makes all the above magic explicit, and as a side effect would
> fix the Linux client sending spurious mtime update requests that
> the procotol already requires to be done implicitly.

Fair enough. In that case, I wouldn't try to optimize away the second
notify_change if the client sets ATTR_MTIME/ATTR_CTIME for now

 We might have to dip down into the fs twice for a truncate, but so be
it. If it becomes a problem then we can consider that more reason to add
a real ->truncate operation.

-- 
Jeff Layton <jlayton@poochiereds.net>