Date: 30 Nov 1999 15:18:16 -0500 From: Randell Jesup <rjesup@wgate.com> To: Robert Watson <robert@cyrus.watson.org>, freebsd-hackers@freebsd.org Subject: Re: Portable way to compare struct stat's? Message-ID: <ybu4se3lomv.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Robert Watson's message of "Tue, 16 Nov 1999 10:38:42 -0500 (EST)"
next in thread | raw e-mail | index | archive | help
Robert Watson <robert@cyrus.watson.org> writes:
>> On a single system, if st_dev and st_ino are equal, you must be referring
>> to the same object. If not, I'd like to hear about it.
>
>This assumption has always caused lots of pain and suffering for
>distributed file system people -- in a distributed file system, the
>requirement that you can generate a unique 32 bit number for each file or
>directory visible in the FS is a fairly arduous one. Either the number is
Quite true, and a real performance problem for some FS designs.
Read some SigOS papers for examples (or below).
Allowing the application to decide if something is the same or not
directly is not a Good Idea. Allowing the OS/FS to determine that for the
application is a Good Idea. Witness the SameLock(lock1,lock2) call in some
OS's (AmigaOS in particular - SameFileHandle(fh1,fh2) or
SameFile(filename1,filename2) are simple derivatives of SameLock()).
re: AFS, CODA
>each file/directory, only it's 96-bit, which in my book doesn't guarantee
>unique mapping onto the 16 bit dev number and 32 bit inode. This means a
>hash is required, and collisions are possibly. When a collision occurs on
>the hash under Linux, all hell breaks loose :-).
Hell breaking loose can be a real pain
>Rant rant rant.
And a darn good rant at that.
Too bad that the "that's the way it's always been done"/"inodes
were handed down by God" arguments are so hard to overcome. 1/2 :-)
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu4se3lomv.fsf>