On Fri, Nov 07, 2014 at 10:53:08AM -0500, J. Bruce Fields wrote: > By the way, the nfsd code is only using i_version when > IS_I_VERSION(inode), otherwise it falls back on ctime. Do we have some > easy way to check for change attribute support now? Otherwise we're > ignoring it on xfs and btrfs. Both btrfs and xfs set MS_I_VERSION. Btw, could you resend your patches to move this out of s_flags? > > there is no difference anyway, > > as they update the change attribute on every write, > > You mean by that that the change attribute on these filesystems will > reach the disk at the same time as the write, regardless of whether > someone does sync or datasync? Not nessecarily exactly the same time, but vfs_fsync_range will ensure that we flush both all data for the range, and then flush all metadata. With the datasync flag set to 1 we will skip inodes where only the timestamps are dirty. Interestingly ext4 consideres the change attribute a skippable timestamp update, XFS doesn't and btrfs doesn't even try to optimize fdatasync, so we have three different behaviors for three different filesystems here - my previous post was just based on the XFS behavior. > I'm not completely following. So if the spec had a definite statement > one way or the other, would that be good enough to make the distinction > used to? If we could specify the behavior from scratch, what do you > think would be the right choice? > > I find it had to figure out the consequences of the change attribute not > being written at the same time as the write, and whether there's some > reasonable second-best behavior the server can provide in the case it > doesn't write them to disk together atomically. It doesn't currently > seem like there's much a client can really count on after boot. Tom, do you think it's reasonable to propose an errata for 4.0/4.1 that explicitly allows the behavior of updating the change attribute in memory on a DATA_SYNC4 write, but not nessecarily persisting it? What about COMMIT? Using datasync there would provide even more benefits in practice there. I guess I just need to take this to the ietf list. -- 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
