[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: deprecating /usr as a standalone filesystem?



md@Linux.IT (Marco d'Itri) writes:

> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
>
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
>
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"
>
> -- 
> ciao,
> Marco

Home case:

/ is a small raid1 that is directly booted into without initramfs
/usr is on lvm on raid5

Without a seperate /usr this would require the use of an initramfs and
seperate /boot partition or much more space.


Work case:

/ is an initramfs
/usr is shared over network for many hosts


Useability reasons:

- If fsck repairs anything while checking / the system has to
  reboot. All other filesystems can just continue. By splitting / and
  /usr there is less of a chance of / needing repair saving the reboot.

- Fsck for / is run first and then other filesystems can run in parallel.

- Less chance of filesystem corruption on / if /usr is another
  filesystem. That also means I can still boot even when /usr is
  damaged and then try to repair it.

- / is small and relatively constant while /usr grows all the
  time. With / outside LVM it can be booted directly and /usr inside
  LVM allows easy resize when more space is needed.

- / contains data that might need to be encrypted (/etc) while /usr
  can be left plain for more speed/less cpu usage.

MfG
        Goswin


Reply to: