Subject: Re: Volunteers to test some kernel code...
To: Gandhi woulda smacked you <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/16/1999 09:44:58
On Wed, 16 Jun 1999, Gandhi woulda smacked you wrote:
> On Tue, 15 Jun 1999, Brett Lymn wrote:
[and I wrote the part in "#"'s]
> # 1) The generation number is attached to a vnode which is ok - you get
> # one of those when you open the file _but_ the vnode goes back onto the
> # free list when the file is closed. If I understand things correctly
> # the vnode can then be recycled if there is the need for another file
> # (I know the vnodes linger around but at some point they start getting
> # recycled). This means that if you open the first file again you get a
> # filehandle with a new generation number which will not match the list.
> I thought the generation number was only generated on a newfs or a
> fsirand on a filesystem. I know that if someone has a file open across
> NFS and you fsirand the filesystem it's on, the next access returns
You're correct about when generation #'s get changed. But they do also get
changed on inode allocation. Check out ffs_valloc() under the "Set up a
new generation number for this inode." comment. :-)
> I would think you'd use dev/ino/generation triplets, actually -- the
> generation number is there to make sure someone hasn't supplanted the binary.
Right! That's exactly why its changed in ffs_valloc, and why it's needed.
Since all the info in a filehandle is needed, I think it'd be much better
if they were used instead of dev/ino/gen# tuples. I think using explicit
dev/ino values in the interface is wrong, and will generate a lot of
resistance (from me :-) over something which really isn't an essential
point of the design. :-)
> # 2) Generation numbers do wrap around, eventually.
> ...which means what, exactly?
I think the thought was that if the generation #'s were tied to the
in-memory inode, that eventually that number would come back, and the
wrong file would be validated.