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@xxxxxxxxxxxxxxx> -- 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
