Date: Sat, 20 Nov 1999 16:43:04 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Wes Peters <wes@softweyr.com>, "Daniel C. Sobral" <dcs@newsguy.com> Cc: John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <v04210107b45cb84c49f1@[128.113.24.47]> In-Reply-To: <3836F873.D3B989FE@softweyr.com> References: <XFMail.991118185611.jdp@polstra.com> <3836DF98.9A84EC44@newsguy.com> <3836F873.D3B989FE@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:37 PM -0700 11/20/99, Wes Peters wrote: >"Daniel C. Sobral" wrote: > > It was stated before that FreeBSD complies with POSIX except where > > POSIX is broken. Well, it's broken here. st_dev+st_ino *can't* work > > with modern, distributed filesystems (without undue overhead). > >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. Hmm, I'm not so sure. In AFS land we have 162 different cells "in AFS". Those cells are made up of 394 different machines which are exporting files. AFS exports "volumes", not bsd-style file systems. If you use st_dev to indicate the "cell", you will run into problems because a given volume can be mounted at multiple spots in the same cell. You can't use st_dev to indicate the server-machine being used either, because a volume can be replicated across multiple servers. It can also move from one server to another, without the AFS client ever seeing any event. So, st_dev pretty much has to be related to the AFS volume. I don't know the maximum number of volumes that a single AFS cell can have, but at RPI there's at least one volume for every userid (say, 10,000 volumes there), plus one backup-volume for every userid (so, 20,000 volumes), plus at least a few thousand more volumes for things unrelated to userids. Home directories are not replicated volumes, but many of the remaining volumes are replicated. Each replicated volume would have to be considered two separate volumes as far as this check is concerned. The "read-write" volume, and the "read-only" volume. My guess is that we (RPI) have over 32,000 volumes, and we're certainly not the largest AFS cell. It is perhaps useful to note that the "AFS volume ID" for my home directory is 536874209, although I am certainly not implying that we have that many different volumes in our cell. Given that there are over 160 cells, I'm pretty sure st_dev is simply not up to the task of giving a unique identifier for each volume which is mounted on a given AFS client machine. It is probably true that any one volume can not have more than 2^32 files in it. It is also probably true that you can not assume that the per-volume max-count of unique files is significantly smaller than 2^32 either. It's got to be at least 2^16, I would think. >Discussions (with strong, valid reasons) about expanding >the size of ino_t should be carried out on -arch. Mind you, I don't know what to suggest as a solution to this, so I don't have anything to send to -arch... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute 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?v04210107b45cb84c49f1>