Date: Tue, 28 Nov 2000 23:28:52 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, "Daniel C. Sobral" <dcs@newsguy.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Message-ID: <p04330101b64a34131126@[128.113.24.47]> In-Reply-To: <200011272057.PAA96878@khavrinen.lcs.mit.edu> References: <200011270434.eAR4Y7D45315@mobile.wemm.org> <Pine.NEB.3.96L.1001127004343.36087A-100000@fledge.watson.org> <200011271520.KAA94212@khavrinen.lcs.mit.edu> <3A22C835.2D84B426@newsguy.com> <200011272057.PAA96878@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 3:57 PM -0500 11/27/00, Garrett Wollman wrote: ><<On Tue, 28 Nov 2000 05:46:45 +0900, "Daniel C. Sobral" ><dcs@newsguy.com> said: > >> POSIX doesn't match reality in this respect. Any application which >> follows POSIX here is broken in Real Life. > >I think you'd have a hard time convincing most people of that. Being >able to recognize files on the basis of their (device, inode) pairs is >fundamental to UNIX going all the way back. (There is no requirement >that the device and inode actually have those particular meanings, or >are persistent across mounts; under NFS they do not and are not.) >Any file system which does not provide for this behavior is broken in >real life. Given that there are already distributed file systems which CANNOT give a unique device+inode pair for a given file (due to the limited range of the device and inode variables), how can we stick to the POSIX definition? It seems to me that if we're really going to talk about huge file systems, then we either have to increase the range of the device and inode variables, or we have to come up with some other way to determine if two filenames are pointers to the same underlying file. I am not eager to abandon POSIX on this, so philosophically I would be happy to just increase the range of the device and inode variables. But how disruptive of a change would that be? If that is too disruptive of a change, than how DO we address filesystems with trillions of files? Claiming that such a filesystem is "broken" misses the point. Such filesystems already exist, and given the absurdly low price of disk space, they are almost certain to become more common. We can't just say "you're broken" and have those filesystems disappear. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p04330101b64a34131126>