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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:22 EST