Messages in this thread |  | | From | devnull@spaans ... | Date | Wed, 13 Sep 2000 17:08:13 -0400 | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST) From: Trond Myklebust <trond.myklebust@fys.uio.no>
You might be able to steal a couple of bytes and then rewrite ext2fs to mask those out from the 'i_generation' field, but it would mean that you could no longer boot your old 2.2.16 kernel without trouble on existing clients.
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?
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?
- Ted - 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/
|  |