Date: Fri, 7 Jun 1996 12:49:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: stefan@Promo.DE (Stefan Bethke) Cc: terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Breaking ffs - speed en Message-ID: <199606071949.MAA03773@phaeton.artisoft.com> In-Reply-To: <n1377974155.17960@quick.Promo.DE> from "Stefan Bethke" at Jun 7, 96 11:50:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606071949.MAA03773>