Date: Thu, 1 Mar 2001 05:10:06 +0000 (GMT)
From: Terry Lambert <tlambert@primenet.com>
To: scott_long@btc.adaptec.com (Long, Scott)
Cc: wollman@khavrinen.lcs.mit.edu ('Garrett Wollman'), arch@FreeBSD.ORG
Subject: Re: Arch question for a UDF FS driver
Message-ID: <200103010510.WAA16907@usr05.primenet.com>
In-Reply-To: <E0BFB46945D5D411BB590000D11ABE920334A2@btcexc01.btc.adaptec.com> from "Long, Scott" at Feb 28, 2001 08:59:46 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber > > any collisions into the space above 2**31. You would still need to > > keep some state when there is a collision, but if the Ids are > > assigned sequentially then you are likely to win most of the time. > > Interesting idea. Like I said, consuming 32 bits within the life of the > filesystem is going to be pretty hard. > > > I don't see what this has to do with vget(), however. > > not vget() itself, the vget vfsop. Unless I'm totally clueless here, the > vget vfsop is supposed to return the vnode that repesents the passed in > ino_t. The question to ask yourself is "under what circumstances do I care about the ino_t?". My personal take would be to appeal to the Apple people here, since they have already implemented one of these things, and know how they did it, and the technical reasons why. My gut reaction would be to give ownership of the vnodes to the FS itself, and ignore the problem (search for the string "TFS" in the FS releated kernel code to see what I mean). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103010510.WAA16907>