On Wed, Apr 05, 2017 at 10:05:51AM +0200, Jan Kara wrote: > 1) Keep i_version as is, make clients also check for i_ctime. That would be a protocol revision, which we'd definitely rather avoid. But can't we accomplish the same by using something like ctime * (some constant) + i_version ? > Pro: No on-disk format changes. > Cons: After a crash, i_version can go backwards (but when file changes > i_version, i_ctime pair should be still different) or not, data can be > old or not. This is probably good enough for NFS purposes: typically on an NFS filesystem, results of a read in the face of a concurrent write open are undefined. And writers sync before close. So after a crash with a dirty inode, we're in a situation where an NFS client still needs to resend some writes, sync, and close. I'm OK with things being inconsistent during this window. I do expect things to return to normal once that client's has resent its writes--hence the worry about actually resuing old values after boot (such as if i_version regresses on boot and then increments back to the same value after further writes). Factoring in ctime fixes that. > 2) Fsync when reporting i_version. > Pro: No on-disk format changes, strong consistency of i_version and > data. > Cons: Difficult to implement for filesystems due to locking constrains. > High performance overhead or i_version reporting. Sounds painful. > 3) Some variant of crash counter. > Pro: i_version cannot go backwards. > Cons: Requires on-disk format changes. After a crash data can be old > (however i_version increased). Also, some unnecessary invalidations. Which maybe can be mostly avoided by some variation of Neil's scheme. It looks to me like option (1) is doable now and introduces no regressions compared to the current situation. (2) and (3) are more copmlicated and involve some tradeoffs. Also, we can implement (1) and switch to (2) or (3) later. We'd want to do it without reported i_versions decreasing on kernel upgrade, but there are multiple ways of handling that. (Worst case, just restrict the change to newly created filesystems.) --b. -- 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
