On Wed, Nov 21, 2018 at 12:17:21PM +0000, Roger Leigh wrote:
> Hi folks,
>
> I've been following the discussion with interest. It's certainly not a new
> discussion, since I remember debating it a good few years back, but there
> are still the same opinions and thoughts on the topic that I remember from
> back then.
>
> Some general points to consider:
>
> 1) A separate /usr serves no practical purpose on a Debian/Devuan system
>
> Historically, /usr was separately mountable, shareable over NFS. With a
> package manager like dpkg, / and /usr are an integrated, managed whole.
> Sharing over NFS is not practical since the managed files span both parts,
> and you can't split the package database between separate systems. Modern
> disk sizes make partitioning a separate /usr unnecessary and undesirable.
> (Both are of course /possible/, but there is precious little to gain by
> doing so.)
>
> Other systems, like the BSDs, have the effective split between base (/)
> and ports (/usr/local). / and /usr are still effectively a managed whole
> containing the "base system".
>
> With those points considered, merging / and /usr would make sense. Though
> equally, keeping the separation doesn't hurt *if they are on the same
> filesystem*. If they are to be merged, then there are two possibilities:
> moving /usr to / or the contents of /* to /usr.
>
> The point about /usr being a good place for "static" content is a
> reasonable one. But for better or worse, / is "the system". It's still
> part of the managed whole, and hiving off a static /usr rather than hiving
> off the variable changing content isn't really doing more than adding extra
> unnecessary complexity.
>
> 2) Moving the content to /usr doesn't preclude moving it to / later
>
> RedHat/systemd have decided to move everything to /usr, and Debian have
> decided to copy this as they have for most systemd-dictated changes. I'd
> prefer it to be the other way around; it's cleaner and it's what we would
> choose given a clean slate. However, when multiple filesystems are in use,
> /usr is often larger and this is potentially the safer move *for upgrades*.
>
> dpkg permits any directory in the filesystem hierarchy to be replaced by
> a symbolic link. If the contents of /bin, /lib etc. are moved to /usr/bin,
> /usr/lib etc., they can be replaced by symlinks so that /bin/sh and
> /lib/ld.so and other fixed paths continue to work correctly.
>
> Conversely, /usr can be symlinked to /. This permits /usr/bin/perl to
> continue to work even if the interpreter is in /bin.
hendrik@midwinter:~$ ls /usr
bin games include lib local lost+found sbin share src
hendrik@midwinter:~$
better to symlink /usr/bin to /bin, /usr/games to /games, and so forth.
Otherwise recursive file scans can easily end up looping through /,
/usr, /usr/usr, /usr/usr/usr, and so forth.
-- hendrik
...
...
>
> Like a lot of systemd-driven changes, unifying these filesystems is
> technically possible, slightly desirable, but at a huge practical cost. The
> main costs are the severe risks taken to migrate essential system files and
> rearrange the root filesystem during an upgrade. Given that from the user's
> and sysadmin's point of view, the system behaves the same both before and
> after the upgrade, they are being required to undertake a large risk for
> *almost zero* practical benefit. Personally, I would argue this should only
> be done for fresh installations. I don't think the potential for
> near-irreparable damage to running systems is acceptable. Depending upon
> the configuration, there's a risk of the system no longer being bootable, of
> the system being in a corrupt state if the migration fails due to the /usr
> filesystem not having enough space to migrate the files, or dpkg not being
> able to revert or complete the operation if interrupted.
Better for the /usr to be corrupt than for / to become corrupt.
With merely a corrupt /usr, it's still possible to use system recovery
tools in / to recover the system. Unless, of course they've all been
moved to /usr with symlinks.
-- hendrik
::
Re: [DNG] /usr to merge or not to m…
