Resize home partition taking space from root partition?

bernik · 2023-06-06 22:53:46

Hi everyone!

So I've correctly installed Arch and after 1 month of usage I have the following disk/partition layout:

❯ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476,9G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot
├─nvme0n1p2 259:2    0   300G  0 part /
└─nvme0n1p3 259:3    0 175,9G  0 part /home

❯ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  295G   82G  198G  30% /
/dev/nvme0n1p3  173G   87G   77G  53% /home
/dev/nvme0n1p1 1022M   84M  939M   9% /boot

Since I found out that maybe I've allocated too much space on the root part and too less on the home part, I'd like to know if it is feasible to transfer some available space from one to another. I thought of doing the following steps:

Backup the whole system
Boot from live arch usb
Resize the root partition (this will give me some unallocated space)
Delete the current /home partition
Create and format a new home partition on `nvme0n1/nvme0n1p3`
Transfer the old /home files to the newly created part

Supposing these steps so far are sound, there are some more steps to be followed of course. What do I have to do exactly to restore the old system without making much of a mess? I'd like to avoid reinstalling from 0 and preserve installed programs, docker images, etc.

Also, while I'm at it, I'd like to ask:

Which are some good root - home size proportions considering I use docker a lot and potentially will install a decent number of programs in the future (right now I've used ~82G)?
Do you have any suggestions for an exclude_files list for `rsync` when cloning the /home partition (like caches, node_modules, site_packages, etc.)?

Thanks.

Last edited by bernik (2023-06-06 22:56:47)

Trilby · 2023-06-06 23:54:28

I'm a broken record on these forums in encouraging diagnosing how disk space is actually filling up before making changes - and that's the case when people have 10-20G of their root partition used. You're using 100G?? How?

bernik · 2023-06-07 10:30:11

Trilby wrote:

I'm a broken record on these forums in encouraging diagnosing how disk space is actually filling up before making changes - and that's the case when people have 10-20G of their root partition used. You're using 100G?? How?

As I stated, basically docker since I heavily use it at work.

❯ sudo du -ahx / | sort -rh
84G     /
69G     /var
62G     /var/lib/docker
62G     /var/lib
61G     /var/lib/docker/overlay2
8,8G    /usr
6,2G    /var/cache/pacman/pkg
6,2G    /var/cache/pacman
6,2G    /var/cache
6,1G    /opt
4,3G    /usr/lib
3,3G    /usr/share

❯ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          198       52        29.01GB   24.63GB (84%)
Containers      69        1         140.9MB   140.9MB (100%)
Local Volumes   8         4         1.09GB    1.973kB (0%)
Build Cache     1249      0         24.18GB   24.18GB

After some pruning I can get to this point:

❯ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476,9G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot
├─nvme0n1p2 259:2    0   300G  0 part /
└─nvme0n1p3 259:3    0 175,9G  0 part /home
❯ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  295G   37G  244G  13% /
/dev/nvme0n1p3  173G   88G   77G  54% /home
/dev/nvme0n1p1 1022M   84M  939M   9% /boot

I suppose I can change the default docker directory and move it to the home partition but Idk if it's a good practice. Apart from this, the starting problem of the question still remains I guess.

Last edited by bernik (2023-06-07 10:40:53)

V1del · 2023-06-07 11:17:55

It's relatively easy to do that and also generally safe and if things work out you don't even need to delete your home partition nor will have to copy stuff over, but still you'll want to have backups of the stuff you can't afford to lose as a failure in these kind of operations can have consequences. You generally need to do this from a live system so you can operate on the unmounted root partition and I strongly suggest you pick up a gparted live disk and just use gparted which will give you an intuitive GUI to do this which will also do all the proper operations in the correct order.

As for rsync commands, ommitting ~/.cache will likely avoid most of the big gotchas you can have here that are not being strictly required to be backed up.

Last edited by V1del (2023-06-07 11:21:46)

bernik · 2023-06-07 12:48:13

V1del wrote:

It's relatively easy to do that and also generally safe and if things work out you don't even need to delete your home partition nor will have to copy stuff over, but still you'll want to have backups of the stuff you can't afford to lose as a failure in these kind of operations can have consequences. You generally need to do this from a live system so you can operate on the unmounted root partition and I strongly suggest you pick up a gparted live disk and just use gparted which will give you an intuitive GUI to do this which will also do all the proper operations in the correct order.
As for rsync commands, ommitting ~/.cache will likely avoid most of the big gotchas you can have here that are not being strictly required to be backed up.

I knew about this procedure and if I understood correctly what gparted is doing under the hood is moving the unallocated part on the right of the home partition before being able to extend the old partition. But I've also read around that this process may take a really long time depending on the size and it's prone to system breaks. That's way I was actually thinking about a complete /home remove and reallocation, leveraging the fact the the root part is independent.

V1del · 2023-06-07 12:59:57

An "in-place" move of the data will still be faster than copying between completely distinct devices. But if you trust your backup and the relevant restoration then you can do that out right of course yes. I don't really see how this is inherently more prone to system breaks than your manual copy operation but you can of course also just remove and recreate the /home partition (... in which case don't forget to update your fstab as the identifiers will likely change).

And if you opt for doing the resizing of root via the terminal you need to ensure you are doing things in the correct order -- i.e. you need to shrink the filesystem on the root partition first and then shrink the partition to match the FS again, afaik none of the CLI clients will do both in one step.

kermit63 · 2023-06-07 13:33:01

bernik wrote:

I knew about this procedure and if I understood correctly what gparted is doing under the hood is moving the unallocated part on the right of the home partition before being able to extend the old partition. But I've also read around that this process may take a really long time depending on the size and it's prone to system breaks. That's way I was actually thinking about a complete /home remove and reallocation, leveraging the fact the the root part is independent.

Your /home partition only has 87G worth of data. It shouldn't take too long with gparted. On my really old system (10+ years) with a 6-year old ssd I don't expect it to take more than 30 minutes for that amount of data.

bernik · 2023-06-07 13:38:54

kermit63 wrote:

bernik wrote:
I knew about this procedure and if I understood correctly what gparted is doing under the hood is moving the unallocated part on the right of the home partition before being able to extend the old partition. But I've also read around that this process may take a really long time depending on the size and it's prone to system breaks. That's way I was actually thinking about a complete /home remove and reallocation, leveraging the fact the the root part is independent.
Your /home partition only has 87G worth of data. It shouldn't take too long with gparted. On my really old system (10+ years) with a 6-year old ssd I don't expect it to take more than 30 minutes for that amount of data.

All right, I'll give it a shot then. You assure me that this procedure doesn't need fstab to be updated etc etc. right? The partitons UUID should remain the same

Last edited by bernik (2023-06-07 13:39:12)

V1del · 2023-06-07 13:49:47

That's correct, since you only manipulate the already existing partitions/filesystems. FWIW I've also done similar procedures at least 10 times for a variety of reasons and have yet had to have one go wrong, but Murphy's law and all that, you mileage may -- but hopefully doesn't -- vary.

bernik · 2023-06-07 19:51:42

Thanks everyone. While we're still at it, do you have any recommendation for backing up the whole system (root and home partition)? I thought of using rsync but maybe there's something more solid since I would like to avoid using it with the wrong options.

Last edited by bernik (2023-06-07 19:52:42)

Arch Linux

#1 2023-06-06 22:53:46

Resize home partition taking space from root partition?

#2 2023-06-06 23:54:28

Re: Resize home partition taking space from root partition?

#3 2023-06-07 10:30:11

Re: Resize home partition taking space from root partition?

#4 2023-06-07 11:17:55

Re: Resize home partition taking space from root partition?

#5 2023-06-07 12:48:13

Re: Resize home partition taking space from root partition?

#6 2023-06-07 12:59:57

Re: Resize home partition taking space from root partition?

#7 2023-06-07 13:33:01

Re: Resize home partition taking space from root partition?

#8 2023-06-07 13:38:54

Re: Resize home partition taking space from root partition?

#9 2023-06-07 13:49:47

Re: Resize home partition taking space from root partition?

#10 2023-06-07 19:51:42

Re: Resize home partition taking space from root partition?

Board footer