Messages in this thread | | | Date | Wed, 13 Sep 2000 23:32:44 +0200 (CEST) | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> |
| |
>>>>> " " == Theodore Y Ts'o <tytso@MIT.EDU> writes:
> Why? i_generation is a field which is only used by the NFS > server. As far as ext2 is concerned, it's a black box value. > Currently, as I understand things (and you're much more the > export on the NFS code than I am) all 32 bits of i_generation > is used to enforce uniqueness of the NFS file handler across > the recycling of the inode (i.e., the inode is deleted, and > then reused for something else). Is that right?
Yes. In effect you have a 32-bit counter that serves as a guarantees that an inode is not reused 'within a reasonable period of time'.
> If we were to steal, say, 8 bits of i_generation to provide a > subsecond indicator of freshness of the attributes by shoving > those 8 bits into the NFS microseconds field, this shouldn't > cause any incompatibilities, should it? (Of couse, you would > mask out those 8 bits for the NFS file handle generation > algorithm, which you would only have 24 bits, which still > should be enough for its purposes.)
> My understanding of the games played by the i_generation field > and the NFS file handle is that it's not visiable to NFS > clients. True, it would mean a certain amount of confusion for > those clients that kept the filesystem mounted across a > transition between an old 2.2.16 kernel and a reboot to a new > kernel that interpreted the i_generation field differently, but > that should be the only compatibility problem I can think of.
> Am I missing something?
We'd want to make an implementation that is generic and fits all 'commonly used' UNIX filesystems. That means that we don't want to apply an ext2-specific hack at the VFS or nfsd levels. The inode-generation field is a feature on several filesystems which already support sub-second timestamps.
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |