The root filesystem

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

The root filesystem

Post by mystran »

I'd like some thoughts from fellow developers. In Unix style systems, there's a root filesystem, which is just a normal filesystem, mounted during system initialization, and then typically unmounted as the last thing before a reboot (or remounted read-only to avoid unmounting it at all).

The more I think of this, the more it seems kinda silly to me...

It makes sense to have a "root filesystem" in the sense of having a root directory, and mounting other filesystems there. Even Windows internally has something like this, if I'm not complete mistaken. This could however be completely virtual, a special filesystem that only exists in memory while the system is running. That way if could provide devfs and procfs like functionality directly, with the advantage that they would be always available.

So is there any real advantage of actually having the root filesystem be a real filesystem on a disk? The only advantage I can think of, is having "init" process be a regular binary on the root filesystem, which can then be loaded from disc during startup just like any other process, but I'm not convinced this is good enough reason, especially as I'd rather avoid having Unix "init" like father-of-all process anyway.. and nothing prevents configuring the kernel to automount a certain filesystem at certain mountpoint and starting a certain process from said filesystem to take care of loading rest of the system... or even loading a special process as a multiboot module, which gets loaded as the first user process, which then issues system calls to mount the initial filesystem and whatnot..

Any thoughts?
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
ehird
Member
Member
Posts: 214
Joined: Thu Mar 15, 2007 8:48 am

Post by ehird »

There's a lot more in the root FS than that. You don't want to carry it all in memory.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: The root filesystem

Post by Brendan »

Hi,

If you create a file or directory in the root directory (e.g. "touch /foo" or "mkdir /bar") then you'd probably want that file or directory to stay there after a reboot. To do this you'd need to mount a real file system at "/" so that entries in "/" aren't lost after a reboot.

Of course on most *nix OSs you could (probably) mount a RAM disk at "/", then use a script to create sub-directories in "/" before mounting other file systems. This is harder to automate though - you'd need to change the script and create the file or directory in the RAM disk (rather than just creating the file or directory in the root file system).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Libera.chat IRC: brynet
Location: Canada
Contact:

Post by Brynet-Inc »

Loading all that stuff into a "ramdisk" would be silly.. waist of memory..

I think the file-system hierarchy of UNIX-like systems is great..

Also some people like multiple partitions on a drive.. I've never liked making more then one on a single drive, It's never made any sense to me...having to worry about resizing.. etc..

Although I always have a slave drive in my systems..

Then again, I'm not a fan of "dual-booting" either.. pick something and stick with it.. or use virtualization if you must..
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

I'm not really aiming for Unix-style file organization, so the issue of populating the root directory is irrelevant. I can just have a "/system" directory which is mounted to whatever filesystem contains system files..

The point about creating files in / is an interesting point. This is ofcourse only possible for the superuser in the first place, so I'm not sure if it's such a huge issue. My actual plan wasn't even really to support creating files in such a semi-filesystem, though I never thought of it explicitly, I admit.

Point was to push the traditional /lib, /bin, /home, /root, /etc, /whatever directories at least one level deeper, under something like /system which would be a mount point for what is a traditional root filesystem, basicly leaving just /proc and /dev (autopopulated devfs like thingie) to the top level, possibly with mount points for removable devices and such..

From the user point of view, I'm possibly aiming closer to Windows like organization, where you never actually get to see the real root of the hierarchy. As it is, in modern NT the drive letters are aliases for mount-points not too unlike Unix (and one can do away with most of them by mounting everything in directories under C: if one wants to).

I still like the idea of not having a "real" filesystem as /, because that way all the real filesystem can be unmounted if necessary..

Have to think some more I guess... plus I've got other things to take care of first, anyway.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
User avatar
bubach
Member
Member
Posts: 1223
Joined: Sat Oct 23, 2004 11:00 pm
Location: Sweden
Contact:

Post by bubach »

Hmm, how do you load the root-fs from disk if you dont have any root-fs to mount the filesystems and drives on? It all seems messy. It makes more sense to me that the root-fs is virtual.
Andrew275
Member
Member
Posts: 30
Joined: Tue Feb 27, 2007 2:29 pm
Contact:

Post by Andrew275 »

In my OS, there is a global object namespace that starts at /

Everything else goes from here. I have a System directory, which holds a lot of in-memory objects, like processes, devices, timers, memory mappings, etc. I mount disks as objects off of the root directory, but they could be mounted anywhere. So my FS layout looks something like this:

Code: Select all

/
|---Boot Disk
|---CD-ROM
|---System
    |---Devices
    |---Processes
etc.
My operating system: Desktop OS
Content management system/forum: Deluxe Portal
User avatar
B.E
Member
Member
Posts: 275
Joined: Sat Oct 21, 2006 5:29 pm
Location: Brisbane Australia
Contact:

Post by B.E »

Andrew275 wrote:In my OS, there is a global object namespace that starts at /

Everything else goes from here. I have a System directory, which holds a lot of in-memory objects, like processes, devices, timers, memory mappings, etc. I mount disks as objects off of the root directory, but they could be mounted anywhere. So my FS layout looks something like this:

Code: Select all

/
|---Boot Disk
|---CD-ROM
|---System
    |---Devices
    |---Processes
etc.
Windows uses the same type of system (but with a \ as it's seperator).
Image
Microsoft: "let everyone run after us. We'll just INNOV~1"
Andrew275
Member
Member
Posts: 30
Joined: Tue Feb 27, 2007 2:29 pm
Contact:

Post by Andrew275 »

Yeah, I liked the whole Windows concept of the Object Manager, etc. and kept it in mind when I created my system. There are a few differences though. For one thing, Windows hides most of its namespace to programs; all they see is \GLOBAL?? if I remember correctly. My OS presents the same namespace everywhere. I also use a lot more named objects, for example, every process and thread can be found in the namespace. Which among other things means you can do stuff like this:

Image
My operating system: Desktop OS
Content management system/forum: Deluxe Portal
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: The root filesystem

Post by Solar »

mystran wrote:So is there any real advantage of actually having the root filesystem be a real filesystem on a disk?
I think that the concept of the "single root" filesystem has its origins in the way computers were used in the "olden times" when Unix was conceived.

There you had a system admin responsible for everything working smoothly. Users connected via terminals and didn't have to bother that /home and /usr were on different hard drives, or even different systems. All the bother was handled by the admin, a person trained and payed for the job.

Since those times, computing has changed in some ways that makes "single root" a legacy instead of a feature, IMHO.

One point is that computers have become mainstream, meaning that "everybody" is his own administrator. Another is the advent of removable media.

Both don't really mix well with "single root". Data that was at /home/user/somedata yesterday is gone today because you removed the DVD-RAM and forgot you mounted it to that directory. You cannot write to /usr/bin because of "no space left on device", but /usr/local/bin works fine (because it's on a different partition). And so on.

"Single root", imho, tries to hide a piece of information from the user that should not be hidden - the fact that there is more than one storage device involved, and what data resides on which device.

The advantages of "single root" can IMHO very well be "simulated" using virtual devices.

Say you have /physical/dh0 and /physical/dvd on the one side, and /virtual/system (mapped to dh0) and /virtual/my_backups (the media name of the DVD-RAM currently residing in /physical/dvd) on the other. If a script refers to /virtual/my_backups, it can throw a tantrum if no DVD-RAM, or the wrong one, is currently inserted.
Every good solution is obvious once you've found it.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

Andrew275 wrote:Yeah, I liked the whole Windows concept of the Object Manager, etc.
Did you ever look at unix /dev or unix /proc? They're pretty much exactly what you're describing.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Candy wrote:
Andrew275 wrote:Yeah, I liked the whole Windows concept of the Object Manager, etc.
Did you ever look at unix /dev or unix /proc? They're pretty much exactly what you're describing.
/proc yes, /dev no. If we ignore devfs hackery like Linux supports (which it's getting rid of again), /dev is a perfectly normal directory, which just happens to contain "files" which are specially marked in the file system as being "device files" and which as such specify "major" and "minor" numbers instead of having file contents.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
ehird
Member
Member
Posts: 214
Joined: Thu Mar 15, 2007 8:48 am

Post by ehird »

That Desktop OS screenshot is very plan9-esque.

(Want a screenshot? "cat /dev/screen | convert2png > ~/screeny.png")
Andrew275
Member
Member
Posts: 30
Joined: Tue Feb 27, 2007 2:29 pm
Contact:

Post by Andrew275 »

Haha.. well, I didn't want to type it out, so that was the next best thing. :p

I do have a VMWare graphics driver, but I don't use it for much yet.
My operating system: Desktop OS
Content management system/forum: Deluxe Portal
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Btw, as a related issue, is the best known approach to listing directories (in userspace) to simply open them (either with same or different call as files) and then issue a readdir-systemcall or something similar to get the next entry?

Can anyone think of anything better?
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Post Reply