Date: Tue, 16 Nov 1999 10:38:42 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Wes Peters <wes@softweyr.com> Cc: Kelly Yancey <kbyanc@posi.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <Pine.BSF.3.96.991116103055.6960A-100000@fledge.watson.org> In-Reply-To: <3830F80F.6456DC5@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Nov 1999, Wes Peters wrote: > Kelly Yancey wrote: > > > > Is there a portable method for determining if the contents of two struct > > stat's are identical? > > 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 assigned locally, or it is assigned globally--if locally, you have to dynamically allocate and track the use of so-called inode numbers, and their mappings to files. That's extremely expensive in terms of memory, processor, et al, to maintain the guise of having an inode number where one doesn't exist. If you go for the global option, you have to manage synchronization if you have replication or weak consistency, etc. Very messy. :-) The only real uniqueness guarantee, in my view, should be the uniqueness of the vnode pointer in the kernel -- that is sufficient to distinguish references to files only where relevant (i.e., for whatever reason, there is a vnode reference to the object in kernel). This comes up in AFS and Coda a lot, especially in operating systems where the kernel requires the uniqueness of a given inode number on a device (Linux)--in Coda/AFS, there is indeed a globally unique fid for 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 :-). In Coda, the fid of a file/directory can change, as if you're running disconnected, you allocate out of a local fid space. When you reconnect, you acquire a global fid for the file based on volume number and file number in the volume. But it's still the same file object. Unique inode number makes even less space if you have a web file system, wherein URLs identify files, but you trying to generate a unique inode num per referenced URLs would be a mess. Unique file numbers really only make sense when you have an inode-based file system, or something like that--sure, somewhere there will be a value uniquely identifying the file (unless fs lookups are queries :-), but it may not easily be mappable onto the inode number namespace, and it may not be possible to do so in a way consistent with inode number behavior, a common assumption in tools like tar that try to use inode numbers to detect hard links. Rant rant rant. Robert N M Watson robert@fledge.watson.org 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 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?Pine.BSF.3.96.991116103055.6960A-100000>