:: Re: [DNG] usr-merge
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [DNG] usr-merge
Peter via Dng said on 29 Nov 2025 07:36:17 -0700

>From:    Steve Litt <slitt@???>
>Date:    Fri, 28 Nov 2025 04:20:36 -0500
>> For the same reason not to have more than one partition per disk: It
>> does nothing for you. If you need to grab space off other disks for a
>> given (former) mountpoint, a bind mount to a directory on the othe
>> disk does just fine.  

>
>At an abstract level, makes sense.
>
>I don't have the details. What is needed to make it work?
>
>Install packages allowing LVM?


I wouldn't use LVM if it were the last software on earth. Ext4 or btrfs
etc is good enough for me.

>Use overlayfs? An alternative to LVM?


Never heard of it, so I can't answer.

>What other ingredients?


Let's say your boot drive is a single partition on an NVMe. You install
your OS on that, as THE single partition.

But that's not enough disk space (let's say it's only 2TB). You also
have a 14TB 7200RPM spinning rust drive at /dev/sda, with a single
partition called /dev/sda1, and you want your /home/peter directory to
go there. No problem. Partition and format your spinning rust drive so
it has one partition, and try your best to give that partition the
label "bindmounts" or something else uniquely human recognizable.mount
that partition as /mnt/bindmounts, or, if you're willing to go against
the Filesystem Hierarchy Standard (FHS), just /bindmounts. For the rest
of this I'll assume you chose /bindmounts. I'll also assume the
spinning rust you just formatted is /dev/sda, and the single partition
containing all the drive's space is /dev/sda1.

Now back up your /home tree, hopefully somewhere off this computer.
Then perform the following commands:

sudo mkdir /bindmounts
sudo mkdir /mnt/whatever
sudo mount /dev/sda1 /mnt/whatever
sudo mv /home /mnt/whatever/
sudo mkdir /home
sudo chmod 755 /home
sudo mkdir -p /home/peter
sudo chown peter:peter /home/peter
ln -s /bindmounts/home/peter /home/peter
ls -l /home/peter

If the preceding command gives you the stuff you'd expect in
/home/peter, then so far so good. Now you need to make your home
directory available at boot, the earlier the better. First things
first, edit /etc/fstab to bind mount to /bindmounts. Add something like
the following to /etc/fstab, assuming your spinning rust bindmounts
partition has UUID 51ef83f7-c103-42cd-fbc6-90ea76019149 :

UUID=51ef83f7-c103-42cd-fbc6-90ea76019149 /bindmounts none
defaults,bind,nofail 0 0

Next, as early in the boot as possible, hopefully right after the
mounts in /etc/fstab are completed, put a command somewhere that does:

ln -s /bindmounts/home /home

The preceding command precede any use of /home . If you're using
sysvinit look in /etc/rc.d/rc5 or whatever, and give it a number that's
one after the inittab mounts get mounted. If you're using runit, I'd
suggest right after the shellscript that brings up and mounts the
filesystems. On Void it's /etc/runit/core-services/03-filesystems.sh,
so your new file to do these particular symlinks would be something
like /etc/runit/core-services/03-filesystems-2.sh . Obviously, back it
up in case a later update or new install erases your new file.

Now, if you reboot it, everything should act as if /home/peter were
still on your NVMe. The real beauty is when you add a few other
directories, which used to be mountpoints. Instead of you having to
guess how much they'll hold, you can just symlink them to corresponding
directories under /bindmounts, and you'll have former mountpoints that
are now completely expandable and shrinkable. Be *sure* to have all
your saved email and email cache symlinked this way, because those take
up huge space.

It would be nice to put /var on /bindmounts, but that might not be
possible, because I think it's possible that Linux starts writing its
logs so early that /symlinks/var has not yet been symlinked to /var .
And of course, you WANT your /usr/ tree on the NVMe to gain spectacular
performance.

I haven't tech edited this, so you'll want to thoroughly test it out on
a VM guest before doing it for real. This technique is 100% Linux,
portable as hell, doesn't require all the layers of LVM which must be
unlayered to recover data, is conceptually simple, and even though it
sounded like a lot of instructions, it's probably doable in 20 minutes.
You could even make a shellscript to do parts of it.

If you do this, please let us all know how it worked out.

SteveT

Steve Litt

http://444domains.com