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

From: Bill Studenmund <wrstuden@netbsd.org>
To: "Julio M. Merino Vidal" <jmmv84@gmail.com>
Cc: tech-kern@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/31944 - Fix to reduce tmpfs memory usage
Date: Fri, 14 Apr 2006 14:10:36 -0700

 --gBBFr7Ir9EOA20Yy
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Apr 14, 2006 at 07:51:14PM +0200, Julio M. Merino Vidal wrote:
 > Hello,
 >=20
 > PR kern/31944 lists three issues that make tmpfs consume too much
 > memory.  The attached patch addresses the first of them.  It does the
 > following:
 >=20
 > - Only keep the node identifier/generation number when deleting a node.
 >   The size of tmpfs_nid is much smaller than that of tmpfs_node.
 > - Avoid keeping nodes that were initialized but then discarded due to some
 >   error.  See the keepit parameter to the tmpfs_free_node function.
 >=20
 > I have read the replies to that PR but the proposed solutions seem to be
 > "not right".  Also, one question that arises... can there be two live fil=
 es in a
 > file system with the same node number?  If not, all those solutions do not
 > seem to address this...
 
 As Steve noted, lots of code assumes that <dev,ino> pairs ID unique nodes.
 Thus all files that stat to the same inode numbers in a given filesystem
 are hardlinks to the same thing.
 
 Thus there should not be two live, distinct files that have the same inode
 #.
 
 The only reason I see for keeping track of old generation #s is so that if=
 =20
 we re-use an inode #, we won't give it the same generation # again.
 
 But the thing about generation #s is that we make them up. We export them=
 =20
 in file handles, and nothing is really supposed to tamper with them. :-)
 
 So one solution is to shove 64-bit generation #s in our file handles. Then=
 =20
 just have one 64-bit counter we incriment each time we create a node. Add=
 =20
 that to someting similar to how we reuse PIDs safely, and we should be=20
 set.
 
 Take care,
 
 Bill
 
 --gBBFr7Ir9EOA20Yy
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)
 
 iD8DBQFEQA/MWz+3JHUci9cRAierAJ40d7xSDkBra16QLV/TLTLV6KIpHACfbBLR
 2/c40gVwmVTu8kj6X6lnqhs=
 =eRTT
 -----END PGP SIGNATURE-----
 
 --gBBFr7Ir9EOA20Yy--