On Sun, Sep 07, 2014 at 12:41:28PM -0400, Trond Myklebust wrote: > I'm still confused as to why we need this change to the client. In > RFC5661, Section 18.30.4 there is wording to the effect that: > > Changing the size of a file with SETATTR indirectly changes the > time_modify and change attributes. A client must account for this as > size changes can result in data deletion. > > There is similar wording in RFC3530 and even in RFC1813 (see section > 3.3.2). Without this sort of guarantee by the server, you could, for > instance, get into nasty situations where the file changes, but the > NFSv3 client doesn't detect it. > > So basically, I interpret the spec is saying that we should be able to > rely on the server figuring this out all by itself. I agree that we > have the special corner case of ftruncate(), but the VFS is still > setting the ATTR_CTIME|ATTR_MTIME flags for us in that case, right? Yes. Looks like the problem is on the server side indeed. nfsd_setattr adds a non-conditional ATTR_CTIME for all calls, but never adds ATTR_MTIME for ATTR_SIZE requests. I'll send a server patch instead. [patch 1 in the series still seems worthwhile for the client, though] -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
