Date: Thu, 01 Mar 2001 20:03:56 -0800 From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert@primenet.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver Message-ID: <3A9F1BAC.B4AE48FD@elischer.org> References: <200103020335.UAA18058@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> > >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.
Under UDF Version 1.0
the "Inodes" are in the same space as the data, but starting with
UDF 1.5 the "inodes" are in a separate 'virtual' address space
so their block numbers are always low, no matter what the number
of data blocks on the medium. Using this virtual block number as an
address will give a number that is small enough to fit in a 32 bit field
unless you have about 4 billion files on the media.
They use one block per 'inode'.
UDF 1.0 is only really used now for DVDs so they will never have
4 billion blocks of data either.
(so we can just use the raw block number)
I do however think it would be a good idea to shift the value of inode #
in stat to 64 bits some time in the future.
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
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?3A9F1BAC.B4AE48FD>