From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Help with re-partitioning disks
Date: Wed, 7 May 2025 20:39:13 -0500 [thread overview]
Message-ID: <6c3dff68-ec9b-ecae-6ccd-92e45951f0ff@gmail.com> (raw)
In-Reply-To: <aBuM0wf559HAtq0n@sysrq.in>
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.
>
> Though if /home is not decrypted right after reboot, it will lead to
> failed mail delivery to maildirs, until I decrypt it.
>
> * 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?
>
> 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.
>
> And the last question: is there point in Secure Boot without FDE?
>
> .
>
This is one of those topics where there is a lot of answers and any of
them can be right. I sometimes find that information is the best thing
to go by. I ran du -shc /* on my system. I took out things like /home
and such. I mostly wanted to share the OS itself. The needed size of
/home can vary a lot. It can be 1GB with lots of room still left over
or many TBs and having to add space all the time. It all depends on
what you need to store there. The OS mostly varies by what you have
installed. On my rig, I have almost a full install of KDE and Kicad,
which is a quite large package. To understand why my /usr has a lot of
space used, Kicad and friends are about 5GBs of space used. With all
that said, this is what I show being used on my system according to the
du command.
0 /bin
146M /boot
0 /dev
152K /efi
22M /etc
957M /opt
42M /root
1.8M /run
0 /sbin
0 /sys
21M /tmp
27G /usr
21G /var
This is my partition sizes.
Part. # Size Partition Type Partition Name
----------------------------------------------------------------
1007.0 KiB free space
1 2.0 GiB EFI system partition efi-part
2 10.0 GiB Linux filesystem boot
3 400.0 GiB Linux filesystem root-part
4 180.0 GiB Linux filesystem var-part
5 150.0 GiB Linux filesystem build-part
189.5 GiB free space
The only thing I wish I could change, make the efi thingy smaller. To
be honest tho, first time with efi and I'd rather it be to big than to
small. I made /boot that size so I could add memtest, Knoppix,
sysrescue and such if I wanted to and still not worry about space.
While I do keep a few kernels and init thingys in there, I do clean it
on occasion.
If you have a KDE based install, the space used should give you a fair
amount of info about the smallest you can go. I suspect that you would
want to have more than that since software is only getting larger. You
can expect /usr to grow for sure. I don't tend to see the rest growing
to much OS wise. The log files in /var usually rotate and then delete
after a while. At some point, it won't grow because of logs anyway.
Just keep in mind the portage tree and distfiles, packages to if you
save the binaries you build, are in /var by default. Oh, I'm on a
merged /usr on my new rig.
I use ext4 here with LVM under that. My OS this time does not use LVM
tho. I wanted to put /usr on / this time. I did make / big enough this
time that I should be good for a long time. I haven't put / on LVM
before tho. I used to put /usr and /var on LVM tho. With a merged
/usr, it made me nervous. I had a large m.2 stick so I just made things
plenty big.
I hope this will give you some info that will help you with what you
chose to do. It should at least give you some minimums if you are a KDE
user. If you use a really tiny GUI then you could still use those sizes
but just have room for growth.
I wish I had this info the first time I installed Gentoo. I had to move
from drive to drive several times before I got it right. I either had
way to much space that was needed somewhere else or not enough and it
kept filling up.
Hope that helps.
Dale
:-) :-)
next prev parent reply other threads:[~2025-05-08 1:40 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 [this message]
2025-05-08 15:04 ` Michael
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=6c3dff68-ec9b-ecae-6ccd-92e45951f0ff@gmail.com \
--to=rdalek1967@gmail.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