On Sat, 29 Nov 2025 21:58:28 -0500
Steve Litt <slitt@???> wrote:

> 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

Hi,
why not simply:

sudo mount /dev/sda1 /mnt
cp -dpR /home/peter/* /mnt/
sudo umount /mnt
sudo mount /dev/sda1 /home/peter

put something like this in /etc/fstab to have it mounted at boot

UUID=xxxxxxxxxxxxxxxxxxxxxxxx  /home/peter     ext4    defaults,comment=x-gvfs-hide        0       2

If the underlying partition /home/peter is big enough (at least same size as /dev/sda1) you can even use it
as a back up and periodically rsync the content of /dev/sda1 to it (obviously with umount/mount dance),

Just my 2 cents.

Ciao,
Tito