Date: Fri, 2 Mar 2001 03:35:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver Message-ID: <200103020335.UAA18058@usr05.primenet.com> In-Reply-To: <200103011420.JAA00305@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 01, 2001 09:20:59 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> >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).
>
> As I have pointed out before, it is a requirement of POSIX that
> distinct files have distinct (device, inode) pairs. The individual
> st_dev and st_ino values are not required to have any particular
> meaning except when used together in this way. (So, it's possible to
> treat the pair of members as a single 64-bit quantity, should that be
> desired, provided that uniqueness can be guaranteed.)
I like the idea of treating the 64 bit value as opaque, though
there could be collision issues with actual device identifiers.
I think the way Solaris dealt with this was to start using the
address vector instead of the major number for the dev_t; this
also saves a hash lookup on an NFS vonverion of file handles to
structure pointers.
For the DVD case (UDFFS) in question, this number will be zero,
if it's considered as the high order bits, so avoiding zero
might be necessary.
I think that you could probably argue that the {st_dev,st_ino}
set are unique only for that pair, and that there might be yet
another value required on top of that to guarantee that you can
uniquely idenitfy a file (e.g. {st_uniqueid,st_dev,st_ino}, with
the type of st_uniqueid being bit packed, with the high bit as
a continuation bit, or otherwise including an st_stat_version or
whatever).
I think that off_t being assumed to be 64 bits (long was used,
for only 32 bits) is also kind of a lame restriction.
INRE: the use of the inode to generate entity id's: I'm not too
familiar with how they are used architecturally (only that they
exist); is there support for handling has collisions (e.g. the
id is treated as a hash instead of a uniqueid), or otherwise
changing the calculation used? This would seem to me to be a
big limitation in papches, allowing a single server to only
support MAX(ino_t) entities.
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?200103020335.UAA18058>