The following reply was made to PR kern/31944; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	yamt@mwd.biglobe.ne.jp
Subject: Re: pkg/31944
Date: Tue, 7 Mar 2006 13:20:56 -0500

 On Mar 7,  8:33am, thorpej@shagadelic.org (Jason Thorpe) wrote:
 -- Subject: Re: pkg/31944
 
 | 
 | On Mar 7, 2006, at 7:36 AM, Christos Zoulas wrote:
 | 
 | > Right, but it does not matter. The probability that the same  
 | > generation
 | > number gets allocated to the same inode is miniscule.
 | 
 | Would using a random generation number be better?
 
 Using a linear congruent random jenerator would be cheap and easy, but I
 not sure if it is going to be a lot better (and you have to make sure that
 the cycle frequency is > 2^32 - 1). But the real issue is why does tmpfs
 need a generation number? It should be able to do:
 
 	nnode->tn_id = tmp->tm_nodes_last++;
 
 in the inode-reuse case to get a unique inode # anyway. With inodes being
 64_bit this will take a long time to run out. Even if it does run out,
 you can start using the generation number then. Is 2^96 good enough now?
 
 	nnode->tn_id = tmp->tm_nodes_last++;
 	if (tmp->tm_nodes_last == 0)
 		tmp->tm_gen_last++;
 
 and in tempfs_getattr:
 
 	va.va_gen = tmp->tm_gen_last;
 
 christos