On Sat, 20 Nov 1999, Wes Peters wrote:
> "Daniel C. Sobral" wrote:
> >
> > Wes Peters wrote:
> > >
> > > It's not broken in this case. 2^16 (st_dev) is certainly enough to uniquely
> > > indentify all mounted filesystems, and 2^32 is (by definition) enough to
> > > uniquely indentify each of the files on a filesystem. Discussions (with
> > > strong, valid reasons) about expanding the size of ino_t should be carried
> > > out on -arch.
> >
> > Just to expand a little bit more, some distributed filesystems *do
> > not* have a unique identifier like the inode.
>
> So then the FreeBSD client software should create one? Do they just assign
> a random number as the st_ino when stat'ing the file?
The problem isn't creating a unique number for a file, it's maintaining
the consistency of that unique number over time -- the POSIX quote in
question wanted the number to continue to identify the file over more than
the single stat reference. Otherwise, we could assign random numbers,
incrementing numbers, zero, etc, each reference. Using a unique 32-bit
number to identify a file uniquely doesn't work for a large class of file
systems, and therefore would appear to be an fs-specific piece of
functionality -- something that should not be exposed in an fs-general
way--i.e., in the VFS, which is supposed to describe features common
across file systems.
Robert N M Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
