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
> ESTALE.

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.

Take care,

Bill