From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Help with re-partitioning disks
Date: Thu, 08 May 2025 16:04:06 +0100 [thread overview]
Message-ID: <8567884.NyiUUSuA9g@rogueboard> (raw)
In-Reply-To: <aBuM0wf559HAtq0n@sysrq.in>
[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]
On Wednesday, 7 May 2025 17:39:47 British Summer Time Anna wrote:
> Hi! I'm not satisfied with my partition layout, so I'm considering
> changing it. It currently looks like this (/dev/sda and /dev/sdc are
> SSDs, /dev/sdb is HDD):
>
> $ lsblk -A -o NAME,MODEL,SIZE,FSUSED,MOUNTPOINT,FSTYPE
> NAME MODEL SIZE FSUSED MOUNTPOINT FSTYPE
> sda Samsung SSD 850 120GB 111,8G
> ├─sda1 128M 36M /boot vfat
> ├─sda2 45G 40,1G / ext4
> └─sda3 66,7G 50,5G /home xfs
> sdb SAMSUNG HM321HI 298,1G
> └─sdb1 298,1G 13,1G /mnt/storage ext4
> sdc Micron_1100_MTFDDAK256TBN 238,5G
> promise_fasttrack_raid_member ├─sdc1 39,1G
> 27,3G /var xfs
> └─sdc2 199,4G 144,5G /home/cyber xfs
>
> It's currently full of ugly workarounds: at least 20G belong in /var
> rather than /home.
>
> My wishes for the new layout are:
>
> * Encrypted /home partition. The rest of the system should stay
> unencrypted so it could be restarted by someone else without my
> intervention.
You can use fscrypt with ext4 or f2fs and each user will be able to have their
individual home directory encrypted and decrypted transparently with their
login credentials using PAM.
Or you can use luks for whole fs/partitions.
> Though if /home is not decrypted right after reboot, it will lead to
> failed mail delivery to maildirs, until I decrypt it.
You can look at alternative arrangements for mail if this is a problem -
others have commented already.
> * Flexibility. I don't want to face this ugly situation again.
>
> If I had only one disk, I'd just make one big root partition. But
> there are two SSDs, and I could need more than the smallest (111,8G)
> disk allows to fit. I could combine them into singe logical partition
> using LVM.
>
> If I decide to proceed with LVM, XFS will be a bad choice because it
> cannot be shrinked. So I'll need a different filesystem, like ext4,
> Btrfs or maybe even ZFS?
I'm not entirely clear what is the ugly situation you mention, or what may be
your current and emerging storage requirements. More space for home?
Applications? General data? Redundancy? Frequently changing storage space
requirements for home or for some other directory/fs?
There are different ways to achieve any of the above. You could use LVM with
ext4 or other fs types. Or instead you could just use btrfs with '-d single'
to add the SSD disks together into one large linear storage space. You could
have /home as a subvolume and /var as another subvolume on the same btrfs fs.
You can have further subvolumes nested within the above if required and
snapshot them separately. Each of them will share the overall fs size, thus
'flexing' their space usage as they need to, without you having to resize
individual fs/partitions. Some planning up front would be required.
Managing backups is relatively easy with btrfs snapshots and can be automated.
However, you must keep an eye on space taken up by snapshots if you store them
on the same fs, because btrfs won't like running out of space.
Since /dev/sdb is HDD, you can 'mount --bind' /var, a swapfile (or create a
partition) and any other frequently re-written fs on /dev/sdb, instead of your
SDDs. That said, SDDs are quite resilient these days - a spinning drive could
potentially die before your SSD.
> Booting without initramfs will not be possible anymore, so I'll likely
> need more disk space (how much?) for /boot, which can not be a logical
> partition if I wish to continue using EFI stub kernels.
Booting without an initramfs will still be possible, there's a lot you can
include within a unified kernel these days. Especially so if you do not need
to encrypt the whole of the OS.
> And the last question: is there point in Secure Boot without FDE?
It depends on what you are trying to protect yourself from:
https://xkcd.com/538/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-05-08 15:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 16:39 [gentoo-user] Help with re-partitioning disks Anna
2025-05-07 17:16 ` Eli Schwartz
2025-05-07 19:13 ` Wol
2025-05-07 19:53 ` Eli Schwartz
2025-05-07 19:43 ` Anna (navi) Figueiredo Gomes
2025-05-08 1:39 ` Dale
2025-05-08 15:04 ` Michael [this message]
2025-05-09 10:10 ` [gentoo-user] " Anna
2025-05-09 20:39 ` Wol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8567884.NyiUUSuA9g@rogueboard \
--to=confabulate@kintzios.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox