[Feature Suggestion] UsrMove continued

Serge sergemdev at gmail.com
Mon Oct 8 23:18:10 UTC 2012


Modern Fedora had 14 non-empty root directories:
Original UsrMove had "fixed" just 3 of them. But the rest are still there.
What do you think about fixing them all?

Instead of all these directories we can have it as simple as:
  /os    -- OS, kernel-space
  /usr   -- user-space, shareable, possibly read-only,
  /var   -- variable system data, read-write, non-shareable
  /home  -- variable user data, read-write, shareable
And nothing else.

Changes in depth:
  /home remains unchanged

* /dev, /proc and /sys are used for talking to kernel, they go to /os.

* /boot contains the kernel itself, so /os is also a good place for it.

* /root was initially on a root partition because 'root' user should be
able to login even when all other FS (including /usr) are not mounted.
Since now it can't do anything without /usr anyway, /root dir don't have
to be in /.

* /etc contains data and configs for userspace programs, it's useless
without them, and don't have to be separated. After all GNU autotools
have never been aware of such split in the first place.

* /tmp is not really needed any more. Single /var/tmp temporary directory
is enough, it can be automatically cleaned by tmpwatch as usual
(this also solves the problem of large files not fitting in small /tmp)

* As long as initramfs is able to mount /usr it can certainly mount /var.
There's no need for a separate /run in that case, it just pollutes root
directory, so it can be moved back to /var, it's a variable data directory
after all.

User Experience
* fewer toplevel directories

Benefits to Fedora
* Simpler and cleaner overall file system layout, with full compatibility.
* Clear separation of kernel-space, user-space and files of regular users.
* Improved compatibility with build systems such as GNU autotools who never
  have been aware of the /usr split in the first place
* Minimize difference to other *nix systems, such as Android and Solaris,
  which already use similar approach
* Isolate the vendor-supplied mostly read-only operating system resources
  from the rest, thus allow snapshotting of the OS, and easy lightweight
  container OS duplication

This is not a new feature. It has same reasons and same benefits as
original UsrMove. But there're more:

* Dedicated root partition is not necessary any more

* which gives unique ability for NFS-booted diskless stations: initramfs
  only mounts /home (rw, shared), /usr (ro, shared) and /var (rw, dedicated)
  directly to the initramfs layout.

* In some distant future it may be possible to have multiple operating
  systems installed in subdirectories of a single partition. I.e. user
  would have /F21, /F22 and /F23 dirs, and initramfs just binds /usr, /var
  and /home to /F2*/subdirs. No more partitioning, resizing and moving
  disks around. If you're an Ubuntu user and want to try Fedora you just
  install it on top of the same partition. If you don't like it, you
  only need to remove the /Fedora dir.

* Compat-symlinks would still remain there for a long time, but they can
  probably be hidden from non-root users (UID!=0) with some eyecandy
  kernel module. Alternatively (probably not, but still) they can be
  completely replaced with a special redirecting compat-kernel module.

Obviously this won't go in F18. But it mostly works, you can test it:
0. Get Fedora17 LiveCD
1. Boot it with additional kernel params:
  selinux=0 systemd.log_level=debug systemd.log_target=console init=/bin/bash
2. When you get the shell:
# mkdir /os /os/proc /os/sys /os/dev
# mount --move /proc /os/proc; rm -rf /proc; ln -s os/proc /
# mount --move /sys /os/sys; rm -rf /sys; ln -s os/sys /
# mount --move /dev /os/dev; rm -rf /dev; ln -s os/dev /
# mv /boot /os/; ln -s os/boot /
# rm -f /var/run; mkdir /var/run
# mount -n --move /run /var/run; rm -rf /run; ln -s var/run /
# mv -f /root /etc /usr/; ln -s usr/root usr/etc /
# mount --bind /var/tmp /tmp
# exec /sbin/init
and it should work as usual.

PS: Actually only "selinux=0 init=/bin/bash" is needed in kernel params.
The "systemd.log..." part is there just as a workaround. F17 Live can be
booted without it. F18 works fine for me without it in QEMU, but freezes
on real hardware. Not sure why, it happens with regular F18Alpha too.
Some race condition systemd bug?


More information about the devel mailing list