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

Re: Merging / and /usr (was: jessie release goals)



* Roger Leigh <rleigh@codelibre.net> [130509 13:34]:
> The assumptions here are that a separate rootfs decreases the chance
> of breakage, and that you'll need the rootfs to perform the rescue.

No, the point is that having two file systems reduces the amout of
breakage you get.

All the important stuff is in / while /usr is mostly static data
easily (at least outside /usr/local, and even there more likely
than say /etc) recoverable or not that important if lost.

Also with the tools in / you can usually repair problems in /usr.
There is just the right kernel and just the right versions of all
tools. You can do most of the stuff with some rescue-disc, if
the versions fits. But too often there are differences. And getting
some other tool it misses means you need to either install it in
an ramfs and hope you do not need to reboot or you need to have
some spare partition on the hw left. And you do not have access to
your fstab. While each of those problems is managable alone, they
sum up. Each adds to the time you need. And time is often something
you do not really want to spend in case you have a problem.

And while there is no proof that when having one small and one large
partition, the small partition is less likely to fail than everything
in one large partition together, both reason and experience demand
that this point is quite more than an "assumption".

> Regarding rescue, the initramfs has a rescue shell which I've found
> to be just as useful as single user mode.  Once it has mounted the
> rootfs, you can chroot into that and do whatever you would normally
> do to rescue /usr. [Assuming a separate /usr.]  If it doesn't get as
> far as mounting the rootfs, then you'll need some rescue disc in any
> case.  I find the busybox shell to be just as effective as a rescue
> disc in most cases.

"rescue /usr" in a seperate / + /usr setting usually means making sure
it can be mounted again. (Or to transfer data elsewhere, which is also
much easier when your normal network setup is already available).

> In the case where we're mounting /usr in the initramfs rather than
> having it on the rootfs, there's no practical difference to the
> current status quo (and this is intentional).  The only change is
> that we provide the guarantee that /usr is available before init
> starts.

Or in other words: to make essential functionality not available if
/usr is broken.

        Bernhard R. Link


Reply to: