Date: Thu, 1 Mar 2001 08:54:36 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: "Long, Scott" <scott_long@btc.adaptec.com>, "'Garrett Wollman'" <wollman@khavrinen.lcs.mit.edu>, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver Message-ID: <Pine.NEB.3.96L.1010301084659.65459C-100000@fledge.watson.org> In-Reply-To: <200103010510.WAA16907@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry about that blank e-mail -- here's the real thing :-) On Thu, 1 Mar 2001, Terry Lambert wrote: > > > 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?". So my temptation here is the same as Terry's -- the concept of an "inode number" is fairly dated in that it applies poorly, if at all, to modern file systems (even 1980's file systems). There are, unfortunately, a few apps that make use of the inode number returned by stat -- generally to try and detect hard links (I think tar does this). You should be able to use a hash to prevent most collisions. Really, these applications should be fixed not to use the inode number where possible. In the past I've proposed addressing this by introducing a fsamefile(int fd1, int fd2) interface that would allow an application to determine if two open file descriptors pointed to the same "file" from the perspective of the current file system. Depending on your semantics, I suspect a perfectly acceptable implementation would simply compare the two vnode pointers (let Terry comment on aliasing here). In the past, it has been pointed out to me that this dramatically increases the cost of hard link detection -- as such, maintaining a moderately unique ino_t with effectively constant value (hashed from something fairly constant in the underlying file system) and letting the userland application generate hashes using that field, then resolve hash collisions using fsamefile() would be appropriate. I have an implementation of fsamefile() I've been using here with a fair amount of success, although I haven't adapted any third-party applications to use it. Note that on some platforms (including Linux, last I checked), the ino_t uniqueness property is fundamental to the design of their VFS, and collisions can have *very* nasty affects. In FreeBSD, from the kernel perspective, only the uniqueness of the vnode pointer matters, which is what I try to leverage in the fsamefile() interface (and also samefile() based on paths). As for vfs_vget() -- many of our file systems simple fall back on vfs_stdvget() which just returns EOPNOTSUPP. This is perfectly acceptable. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1010301084659.65459C-100000>