From owner-freebsd-hackers Fri Jun 7 12:56:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16389 for hackers-outgoing; Fri, 7 Jun 1996 12:56:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA16376 for ; Fri, 7 Jun 1996 12:56:04 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA03773; Fri, 7 Jun 1996 12:49:28 -0700 From: Terry Lambert Message-Id: <199606071949.MAA03773@phaeton.artisoft.com> Subject: Re: Breaking ffs - speed en To: stefan@Promo.DE (Stefan Bethke) Date: Fri, 7 Jun 1996 12:49:27 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: from "Stefan Bethke" at Jun 7, 96 11:50:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ ... logical numeric namespace seperate from the actual inode name space ... ] > This somewhat the same the Mac HFS works. While it doesn't provide = > concurrent different name spaces, Actualy, it provides a PRODOS name. ;-). > each file on a HFS volume has a distict ID, which is never reused. Actually, this is directory ID. File ID's are permitted to be reqused. This is the "open file by handle" technology used by keeping folder ID's around. The file ID is guaranteed to be unique for any file on a server over a boot instance... that is, the unique file ID is permitted to change between boots, but the unique directory ID is not. Since files typically outnumber directories by a wide margin, this buys you the ability to restrict directory ID's to a smaller than 32 bit domain and to use a generation count and FS ID as components of the directory for a given volume. 8-). > This way, a user can rename and move files on = > the same volume anyway s/he likes; any program referencing a file (i. e. = > a placed image in a DTP application) will find the file regardless. Mac = > "aliases" (which essentially serve the same purpose as symlinks) also = > work this way. I thought aliases used directory ID's and file names; they can't use file ID's because of the boot instance nature on the original Appletalk servers would cause this to fail. ;-). > The Mac uses only two functional ids: 2 always is the volume root = > directory, and 1 (I think) is the active "System Folder". Yes. Typically, the active system folder is *always* on a local drive, so this isn't a real big issue. The volume root of 2 fits with the UNIX inode number. Obviously, a volume root never has any additional generations associated with it, so if you count from zero, this fits the server mechanism as well. The limitation is that you must export volumes from your UNIX system, instead of portions of volumes spanning a mount point -- exported volumes for Appletalk, like for NFS, cannot span mount points. > Having a comparable mechanism in a FreeBSD file system would allow Mac = > file servers (such as the one included in the netatalk package) to serve = > the files correctly; currently, the file server simulates the ids, so = > after unmounting and remounting the server volume, file referenced by id = > won't be found anymore. The File ID simulation is acceptable over a given boot instance, as I explained. I can provide Apple documentation references, if you have an Appletalk developer's license and have signed NDA, but it's pretty obvious in the discussion of File ID's in the index of the Appletalk book where to find it. ;-). The Directory ID is not allowed to be changed between boot instances, and *could* benefit from a numberic logical name space. However, what I was suggesting was a name space for "well known objects", not "all objects". It almost *depends* on the number of objects being smaller than the set of all objects. I think a seperate, monotonically increasing, 16-22 bit directory ID is probably a better idea for the Appletalk server (this is what we did in the NWU product Appletalk server as part of building the attributed FS under UnixWare). > So what are file names good for? Currently, the serve two purposes: to = > uniquely identify the file for a program that needs to access that file, = > and for a user to tell files apart. I think the difference is reference-by-name vs. reference-by-content. The use of a "well known files" name space of any kind (I picked numbers instead of English names because of reduced storage requirements) is based on the idea that the contents are known, or are known to be "interesting", at least. > symbolic name best identifies a particular file. However, why shouldn't I = > be able to call /etc/passwd "Local User+Password Database", because I can = > remember better for what the file is good? Of course, working in a shell, = > I still would prefer "passwd". This is the Windows 95 shortname/longname (or the Mac 32 byte name/8.3 PRODOS name) scenario. Both names can be used interchangeably. [ ... "personal views" ... ] > So the solution would be to represent the files in a net rather than in a = > tree, allowing for several views on the filesystem. Again, working in a = > shell, this might be confusing and complicated, so I'd rather stick with = > the current model. And, yes, I could simulate this with gobs of symlinks; = > but that awkward. AFS handles that type of thing. I'd really prefer that the "personal views" result from the UI tools rather than actualy FS changes (though you'd probably want some kind of attribution ability in the FS to help implement them). This would overcome the main drawback of personal views: technical support. One of the biggest mistakes Microsoft made, IMO, was the introduction of "desktop themes". Can you picture the poor phone support person saying "now double-click on the computer icon... you don't have one? OK, then click the train... you don't have one? OK, the plasma ball, then. Now drag the little folder into the wastebasket... you don't have one? Do you have a black hole? How about a beaker of acid? ...". Serious problem for support, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.