Can any one help me in Understanding what is Root FS and why it is required?

LinuxDreams · 09-04-2013, 01:52 AM

[LIST=1][*]What is root fs?[*]Why it is required?[*]When root fs will alive?[*]Who is bringing up root fs?[*]When we mount other fs what will happen to root fs?[*]What contents(Directories) will be as part of root fs?

Thanking you in advance...

TenTenths · 09-04-2013, 02:14 AM

http://www.linfo.org/root_filesystem.html

LinuxDreams · 09-04-2013, 05:29 AM

Quote:

Originally Posted by TenTenths

http://www.linfo.org/root_filesystem.html

Please put it in your own words...
This I too have found.

TenTenths · 09-04-2013, 06:01 AM

Quote:

Originally Posted by LinuxDreams

Please put it in your own words...
This I too have found.

No, I'm not here to do your homework. Good luck!

jefro · 09-04-2013, 08:41 PM

A tree needs roots doesn't it?

PTrenholme · 09-04-2013, 09:17 PM

One of the basic design goals of the Multics operating system (from which UNIX, Linux, ... was derived) was that Multics implemented a single level store for data access, discarding the clear distinction between files (called segments in Multics) and process memory. The memory of a process consisted solely of segments which were mapped into its address space. To read or write to them, the process simply used normal CPU instructions, and the operating system took care of making sure that all the modifications were saved to disk. In POSIX terminology, it was as if every file was mmap()ed; however, in Multics there was no concept of process memory, separate from the memory used to hold mapped-in files, as Unix has. All memory in the system was part of some segment, which appeared in the file system; this included the temporary scratch memory of the process, its kernel stack, etc.

From that, the concept of the "root file system" should be clear: it's how you locate anything with which you wish to interact.

For example, if you want to look at one of your memory location, read from /proc/self/mem, etc.

Doug G · 09-04-2013, 11:58 PM

Are you are asking specifically about the rootfs (as you might see listed with df -T)?

If so, as far as I know it's a specialized ramfs built in to kernes from 2.6. It's the filesystem that the initial linux startup code runs from which enables the startup to intialize and mount other storage devices like raid arrays, etc.

In a normal pc system the rootfs filesystem is hidden after the full system gets booted, but you may still see rootfs filesystem serving as the ramdisk if you're running a live linux.

jpollard · 09-05-2013, 09:32 AM

Quote:

Originally Posted by Doug G

Are you are asking specifically about the rootfs (as you might see listed with df -T)?

If so, as far as I know it's a specialized ramfs built in to kernes from 2.6. It's the filesystem that the initial linux startup code runs from which enables the startup to intialize and mount other storage devices like raid arrays, etc.

In a normal pc system the rootfs filesystem is hidden after the full system gets booted, but you may still see rootfs filesystem serving as the ramdisk if you're running a live linux.

Not hidden. The initrd ramdisk used for root during boot is discarded. The way this happens is that the kernel loads the ramdisk from the initrd (a compressed cpio backup), starts using the ramdisk for root to initialize the system, load required drivers, populate the /dev directory (which itself is a memory resident filesystem), and mount the real root (on /mnt specifically). Once the real root is mounted on /mnt, the init process then uses the "piviot_root" system call (linux only), to exchange the kernels view of root with /mnt. After the system call, the ramdisk (the original root) is mounted on /mnt, and the real root is now mounted. The ramdisk is dismounted, which releases the storage used back to the kernel for other uses. Once that is completed, the kernel init process execs the /sbin/init file which then takes over the boot process.

The only time you will see a ramdisk (more likely a tmpfs mount) will be when the system is running diskless.

PTrenholme · 09-05-2013, 11:16 AM

Quote:

Originally Posted by jpollard

[...]The only time you will see a ramdisk (more likely a tmpfs mount) will be when the system is running diskless.

Not exactly. Here's what I see on a Fedora 21 (Rawhide), x86_64, system with 12Gb RAM:

Code:

$ df -T
Filesystem     Type      1K-blocks      Used  Available Use% Mounted on
/dev/md126     ext4      503835744  94837672  383381596  20% /
devtmpfs       devtmpfs    5983820         0    5983820   0% /dev
tmpfs          tmpfs       6024476     10484    6013992   1% /dev/shm
tmpfs          tmpfs       6024476       772    6023704   1% /run
tmpfs          tmpfs       6024476         0    6024476   0% /sys/fs/cgroup
tmpfs          tmpfs       6024476       148    6024328   1% /tmp
/dev/sdb1      ext4      443997724  65996008  355424852  16% /Fedora
/dev/sdc1      btrfs    1953512012 345054168 1053098204  25% /Backups
/dev/sda2      fuseblk   451114224 104676780  346437444  24% /Win7

I haven't checked, but I think the production Fedora releases (and any other distributions using systemd) will be similar.

Doug G · 09-05-2013, 12:01 PM

It sounds like this info from kernel.org is outdated now?

Quote:

What is rootfs?
---------------

Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
always present in 2.6 systems. You can't unmount rootfs for approximately the
same reason you can't kill the init process; rather than having special code
to check for and handle an empty list, it's smaller and simpler for the kernel
to just make sure certain lists can't become empty.

Most systems just mount another filesystem over rootfs and ignore it. The
amount of space an empty instance of ramfs takes up is tiny.

And here's what I get with df -T on a Fedora 19 live usb:

Code:

[root@usb15 ~]# df -T
Filesystem          Type     1K-blocks    Used Available Use% Mounted on
rootfs              rootfs     3096336 2985004     79880  98% /
devtmpfs            devtmpfs   1472896       0   1472896   0% /dev
tmpfs               tmpfs      1486196      76   1486120   1% /dev/shm
tmpfs               tmpfs      1486196   25680   1460516   2% /run
tmpfs               tmpfs      1486196       0   1486196   0% /sys/fs/cgroup
/dev/sdb1           ext4       3863248 1608616   2058384  44% /run/initramfs/live
/dev/mapper/live-rw ext4       3096336 2985004     79880  98% /
tmpfs               tmpfs      1486196      64   1486132   1% /tmp
varcacheyum         tmpfs      1486196  147264   1338932  10% /var/cache/yum
vartmp              tmpfs      1486196       0   1486196   0% /var/tmp

jpollard · 09-06-2013, 05:22 AM

It is outdated.

The initrd can be quite a few MB in size now - and depending on the system, could even be multiple GB in size (though I haven't seen any). The GB sized ones would be able to contain the entire runtime system for a diskless node, and since such systems usually have multiple GB (even mine has 8) there is usually enough spare room for it.

jpollard · 09-06-2013, 05:30 AM

Quote:

Originally Posted by PTrenholme

Not exactly. Here's what I see on a Fedora 21 (Rawhide), x86_64, system with 12Gb RAM:

Code:

$ df -T
Filesystem     Type      1K-blocks      Used  Available Use% Mounted on
/dev/md126     ext4      503835744  94837672  383381596  20% /
devtmpfs       devtmpfs    5983820         0    5983820   0% /dev
tmpfs          tmpfs       6024476     10484    6013992   1% /dev/shm
tmpfs          tmpfs       6024476       772    6023704   1% /run
tmpfs          tmpfs       6024476         0    6024476   0% /sys/fs/cgroup
tmpfs          tmpfs       6024476       148    6024328   1% /tmp
/dev/sdb1      ext4      443997724  65996008  355424852  16% /Fedora
/dev/sdc1      btrfs    1953512012 345054168 1053098204  25% /Backups
/dev/sda2      fuseblk   451114224 104676780  346437444  24% /Win7

I haven't checked, but I think the production Fedora releases (and any other distributions using systemd) will be similar.

Yes, and has been pointed out to them several times, that is a security nightmare the way it is done. All you have to do to create a denial of service is to fill the /run filesystem mount. Services will start failing (can't create logins, can't generate X authority files, can't restart services as pid files fail...) The system can be pushed into OOM without being able to recover...

A tmpfs system cannot have quotas imposed - though you can limit the total size, that doesn't prevent a user from using it all. Since the system sensitive files are also on the same filesystem it becomes trivial to carry out a DOS attack.

Even making /tmp a tmpfs mount makes the system vulnerable.

/dev/shm or /sys/fs/cgroup is not a problem, as only the system itself can create entries.

This is only semi-reasonable for workstations as the damage is only to a single system.

Doing this on a server is just plain stupid.

LinuxDreams · 09-10-2013, 01:47 AM

thank you all.... for discussing this topics at great interest..

YellowApple · 09-10-2013, 01:54 PM

Quote:

Originally Posted by jpollard

It is outdated.

The initrd can be quite a few MB in size now - and depending on the system, could even be multiple GB in size (though I haven't seen any). The GB sized ones would be able to contain the entire runtime system for a diskless node, and since such systems usually have multiple GB (even mine has 8) there is usually enough spare room for it.

I think in most cases, though, such diskless systems maintain one or more additional ramdisks outside the initrd (usually as a separate squashfs) rather than attempting to cram everything into the initrd. IIRC, this is how most "toram" setups work; whether it's more efficient or it's some holdover from LILO complaining about 15-16MB memory holes, I don't know.

jpollard · 09-11-2013, 04:52 AM

Quote:

Originally Posted by YellowApple

I think in most cases, though, such diskless systems maintain one or more additional ramdisks outside the initrd (usually as a separate squashfs) rather than attempting to cram everything into the initrd. IIRC, this is how most "toram" setups work; whether it's more efficient or it's some holdover from LILO complaining about 15-16MB memory holes, I don't know.

Most diskless nodes I've worked with use a NFS root as it is simpler to change configurations/add software without even requiring a reboot.