Filesystem mounting

[Solar]

Gosh, it has been a loooooong time... I'll try to explain it from a user's perspective, in relation to Linux terms.

On Linux, you have your USB stick under e.g. /dev/sdb1. In order to actually use it, it has to be "mounted" somewhere. Modern Linux setups do that automatically, using the volume label as subdirectory name to /media, e.g. /media/USB_STICK and display external drives in your filesystem navigator. Back when this discussion was hot, this wasn't automatic, so you have to see this in relation to those times.

It is not immediately obvious which directory in the filesystem resides on which mounted device. You can peruse the mount list to figure it out, but since a mount point can be a subdirectory of a different mount point, things can get confusing.

On AmigaOS (of course any concept I am talking about in praise is inspired by that noteworthy) things are handled a bit differently.

Let's say we plug our USB stick into an Amiga (that actually has USB ports...). Let's say, for the sake of comparability, that the system recognizes the device as "sdb1:". (Not going into details about device driver handling here, that's a different ballgame. Let's just assume.)

Thus, "sdb1:" is the physical name of the device. It's somewhat specific to the system setup. Another Amiga might recognize the stick under a different device name (just like another Linux box might call the stick "/dev/sdc1" or somesuch). In any case, I can access that stick under that name, without "mounting" it somewhere ("sdb1:/foo/file.txt").

A device also has a logical name, assigned at formatting (i.e., the volume label). Being specific to the device, and any other Amiga would recognize the device under that same name. I can access the stick under that name, too ("USB_STICK:/foo/file.txt").

The third way to access something is through an "assign". I can "assign" a "device name" to a directory, or a list of directories:

Code: Select all

assign FOO: USB_STICK:/foo
assign FOO: sdb1:/foo

With either of the above, "FOO:/file.txt" would be the third way to access that peculiar file.txt on the stick. It is possible to have an assign pointing to more than one directory. (Searching in all of them, writing to the first one in the list.) Where a Linux user would mount a specific drive to /var/log, an AmigaOS user would simply assign LOG: to the desired location, i.e. "doing it the other way around".

I won't go into the pro / con discussion, this is long enough as it is. Just a couple of things I liked very much about this concept:

• SYS: is always the boot device (i.e., you are independent of either physical or logical name of the boot device).
• PROGDIR: is specific to a running process, and always points to the directory the executable is located in (giving access to config files etc.).
• WORK: is your home directory.
• C: is a multi-assign that worked equivalent to $PATH / %PATH%. LIBS: worked similar for shared libraries.
• "File Handlers" could be implemented that provided "devices" that weren't, like HTTP:. (Should be obvious what that one did.)
• The desktop displayed all logical devices, giving easy access to your hard drive partitions, external drives, RAM disk etc.; you could always add assigns as desktop icons for shortcuts.
• "Deferred" assigns wouldn't give you an error if a target device didn't exist at the time of the assign. Instead, the system would prompt you to "Please insert volume FOO: in any drive" when such an assign was accessed. (We are talking floppy times here, you might see where this might be handy.)

Linux has caught up in many areas (most importantly the auto-mounting of plug-in devices and displaying them on the desktop for easy access), but I still think the AmigaOS way to be highly intuitive and flexible, once you get used to it.

[Kevin]

I think most of this is Unix vs. AmigaOS rather than single vs. multiple roots, but there are some interesting points in it. Thanks for writing this up!

If I was to implement the user experience on a single-root system, I would go with a "superroot" that contains only mountpoints (phyiscal names) and symlinks (logical names). Another important point you mention is that mounting things anywhere can be confusing. Leaving this out is a completely orthogonal decision and I could do that with my single-root system as well (and a multi-root system could allow it if it wanted to). I think this would already be very close to what you describe, and up to this point both approaches are mostly equivalent.

Having a way to assign multiple directories a single name looks interesting. Does this basically merge the directory entries of all directories in the list into a common namespace? What happens if two directories have files of the same name? I need to think a bit more about this concept, but it might turn out useful for me.

The other interesting thing are these "deferred assigns". Even though floppies aren't in wide use any more, I think it's really the same for any removable device, be it CD-ROMs, USB sticks or anything else.

Now that I read again what I wrote, I think nothing in what I found interesting is really specific to having multiple roots. I certainly got some new ideas to think about, but they are orthogonal to the question of single vs. multiple roots. It seems to be mostly a matter of taste. (It's a pity, I was hoping to find a good reason why we're accidentally doing the right thing there. )

[Solar]

If I was to implement the user experience on a single-root system, I would go with a "superroot" that contains only mountpoints (phyiscal names) and symlinks (logical names).

I wouldn't call that a "single-root system" anymore.

Of course the data structure of your device handling - the list or hash of devices and their names - has to have a "start", even if you're going multi-root. But I used the term "single-root system" specifically to refer to systems where there is one "/", having a physical representation on a specific device. I.e. if I write to "/file.txt", that data ends up somewhere (the "root" device).

And once you got that, there is no way around the kind of confusion involved with mounting "anywhere", because you have to mount "somewhere". You could restrain the issue of mount points to the top-level root directory, which lessens the confusion somewhat, but you would still have to refer to the mountlist to be sure about whether "/foo/file.txt" resides on the root device, or some device mounted to /foo.

Having a way to assign multiple directories a single name looks interesting. Does this basically merge the directory entries of all directories in the list into a common namespace?

Yes.

What happens if two directories have files of the same name?

As I said, it is a loooooong time since. I would have to fire up - no, I would have to install, configure, and then fire up - my UAE to check out. I would assume that AmigaOS went with a "first listed, first found" strategy. (AmigaOS is very KISS that way.)

Now that I read again what I wrote, I think nothing in what I found interesting is really specific to having multiple roots. I certainly got some new ideas to think about, but they are orthogonal to the question of single vs. multiple roots.

As I said, I see your "superroot without physical representation" as being a multi-root system, essentially. But that is more about linguistic fine print than actual technical difference, IMO.

[Kevin]

You can look at it this way and call this a multi-root system. With this definition you could even take a Linux kernel and build a userland that qualifies as multi-root.

The defining difference I used (without spelling it out or even thinking much about it) is whether you can use normal directory handling functions in order to emnumerate/access/create the mountpoints/drives/whatever, so it would be more about OS properties and the API than about the filesystem layout that uses the OS functionality to build a system (in the sense of what you would call a distribution for Linux).

This property is at the same time he biggest disadvantage that I see with multiple roots: You need additional code in applications to deal with the multiple roots. For example, tyndur's shell does have tab completion for directories, but not for service names (which are the first part in path names) and you can't ls them. Ported Unix programs (which, for better or worse, are reality for most hobby OSes that do a bit more than printing Hello World) get confused if you ever try to use absolute paths and so on.

[Solar]

The defining difference I used (without spelling it out or even thinking much about it) is whether you can use normal directory handling functions in order to emnumerate/access/create the mountpoints/drives/whatever...

Ah, I see. Makes sense, in a way; however I don't believe in "everything is a file" (or a directory), so I would probably not see this as a feature per se. (I very much dislike /dev, /proc and /sys, or at least a major part of what they are.)

I looked up the details of multi-path "assigns", by the way. From the AmigaDOS manual, emphasis mine:

Example 4:

1> ASSIGN LIBS: SYS:Libs BigAssem:Libs PDAssem:Libs

Is a multiple-directory assignment that creates a search path containing three Libs directories. These directories will be searched in sequence each time LIBS: is invoked.

[rdos]

The drive letter approach in DOS/Windows (and RDOS) is clearly superior to the "/" in Linux.

[Solar]

Yeah. Whatever.

[Solar]

...if you assign SYS: to something else for a given program specifically, you basically just virtualized the system volume for it...

That wouldn't work on an Amiga, since libraries are searched by path, but are identified only by name, i.e. a program "virtualized" that way would still get the same already-loaded dos.library as everybody else (as opposed to the dos.library that comes with the new SYS: path).

But I see where you are coming from. With some extra care taken with issues like this, it would indeed make chrooting very easy.