(SOLVED) Almost out of disk space on "/"

4romany · 2022-03-05 16:21:16

I noticed this morning that a "lsblk " shows 92% of the disk space being used on "/":

lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 D4A3-351D 427.3M 12% /boot
├─sda2 ext4 1.0 dd036e1b-4810-4b39-a0d0-ee67e1eed2b4 473.4M 92% /
└─sda3 ext4 1.0 a57159c4-e0ab-41dc-8ffd-1a1b4d22a64f 198.6G 2% /home

I installed Arch on this laptop back in January - I'm pretty sure I used the "archinstall" script to do so. I ran pacman -Scc and that brought "/" down to 76%.

Any suggestions on how to proceed? Reformat and follow the wiki? Some other options? This issue came to light when I tried to do an upgrade and it gave an error about insufficent space on drive. No big deal if I have to wipe and load again - but if there is another way I might try that...

Thanks for any tips...

Romany

Last edited by 4romany (2022-03-07 03:30:22)

Slithery · 2022-03-05 16:37:52

Install ncdu and then run it on / to see what's using the space.

Maniaxx · 2022-03-05 17:00:32

Doesn't harm to do a (read-only) fsck. Maybe you have massive orphaned space.

$ sudo fsck.ext4 -fvn /dev/sda?

Trilby · 2022-03-05 17:16:39

Am I missing it, or is there no indication in your post of how big sda2 actually is?

Head_on_a_Stick · 2022-03-05 17:16:48

The OP only has half a gigabyte for the root partition, which isn't really big enough. EDIT: oops, sorry, wasn't paying attention. Thanks for the correction Trilby.

I would shrink the home partition down to ~9.5GiB then copy the contents of the original home partition into a new partition in that free space, delete the original home partition and expand the root partition into that space. Perhaps even larger than 10GiB for the root partition might be appropriate depending on the use case.

Having said that though I have never seen the point of separate root, home & boot partitions (ESP excepted). I always just use a single partition for the entire system. Or even multiple systems with Btrfs subvolumes for each.

Last edited by Head_on_a_Stick (2022-03-05 17:20:26)

Trilby · 2022-03-05 17:18:56

HoaS, we don't know that - the output only shows have a gig free or remaining available (which has increased now that they ran pacman -Scc). In fact we know that's *not* true as a base install could not fit on half a gig.

If it is a big partition and just being filled by something screaming into the logs, then making the partition bigger will only kick the can down the road a bit. First we should get information on the actual problem: how much space is used, and what's using it.

EDIT: I suppose we can calculate based on 473.4M being 8% of the partition that the partition itself is roughly 6GB. If this is the case, that could be ok for very minimal systems (my root partition use is well below that), but most common desktop systems (with a DE and / or big "apps") would need more breathing room.

Similarly, a rough cacluation would suggest that post-cache-cleaning the used space is roughly 4.5G of that 6G. If all this is correct, then increasing the root partition size would likely be wise.

Last edited by Trilby (2022-03-05 17:31:41)

Mr Green · 2022-03-05 17:23:17

sudo fdisk -l

Might help.... either logs or pacman cache....

4romany · 2022-03-05 19:51:17

So here's output for ncfu....-- / -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
. 6.1 GiB [#################################################] /usr
. 5.9 GiB [################################################ ] /timeshift
. 5.3 GiB [########################################### ] /home
1.0 GiB [######## ] /opt
. 522.4 MiB [#### ] /var
55.7 MiB [ ] /boot
. 9.1 MiB [ ] /etc
. 1.6 MiB [ ] /run
. 924.0 KiB [ ] /tmp

Here's the sizes of the partitions - I have 18G set aside for "/" :

lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 484M 0 part /boot
├─sda2 8:2 0 18.1G 0 part /
└─sda3 8:3 0 219.4G 0 part /home

It looks like I can delete timeshift and get back a third of the space currently allocated to sda2. That should be sufficent for now - I have enough space that running out of disk space is not likely - at least in the near future. I'm still going to re-install at some point to correct that. On my main laptop I just have 2 partitions (not counting swap) - I installed that one w/o using the script. Thanks for the help guys - I learned something! I'll close this thread in a day or 2 just in case anyone has anymore comments...

Trilby · 2022-03-05 22:27:50

There's no need to reinstall to increase the root partition size. Expanding partitions and maintaining the data on them is relatively easy. Shrinking partitions in place and maintaining the data may be possible in some cases, but can be tricky and often it's just not worth the effort.

So the only data at peril is anything in your home partition. If there is anything important there, back it up. Then shrink the home filesystem, then shrink the home parition and increase the root partition sizes, then expand the root filesystem size to fit. Finally clean up the home partition restoring data as necessary (or just start from scratch there and recreate a new user directory).

All that said, 18G should be good for most uses of root partitions. The timeshift data is certainly eating a good share - but even with that, the numbers are just not adding up. My rough calculation in the previous post could be a bit off due to rounding errors in the numbers presented, but that wouldn't account for a difference between 6G and 18G. Your first post shows that partition at 92% full with less than half a gig available - if an 18G filesystem was 92% full, you'd have nearly 1.5G available.

Your last output confirms an 18G partition, but what about the filesystem? What's the output of `df -h`?

Last edited by Trilby (2022-03-05 22:31:44)

4romany · 2022-03-06 02:40:52

This is AFTER I deleted all of the timeshift backup data (which consumed 5.9G). The "/" directory shows 7.4G used out of 18G...

df -h
Filesystem Size Used Avail Use% Mounted on
dev 3.9G 0 3.9G 0% /dev
run 3.9G 1.5M 3.9G 1% /run
/dev/sda2 18G 7.4G 9.4G 45% /
/dev/sda3 215G 4.7G 200G 3% /home
/dev/sda1 484M 56M 428M 12% /boot

Trilby · 2022-03-06 04:42:03

So there's no obvious or objective right answer on whether you should increase the size.

A root partition of 18G would be far more that enough for me, and it would be suitable for a fair range of "normal" desktop use. Some users would want more than 18G, but there'd generally be pretty clear reasons for that need: perhaps they plan on using several big software packages like cuda or tensor-flow or big games like 0ad. Or, if in your case you plan on having timeshift store it's data on your root partition, then that'd be a reason to need more space.

While I know nothing of timeshift, it seems to be a backup-type of utility, and keeping backup data on the same filesystem as the data that needs backing up seems problematic anyhow.

Arch Linux

#1 2022-03-05 16:21:16

(SOLVED) Almost out of disk space on "/"

#2 2022-03-05 16:37:52

Re: (SOLVED) Almost out of disk space on "/"

#3 2022-03-05 17:00:32

Re: (SOLVED) Almost out of disk space on "/"

#4 2022-03-05 17:16:39

Re: (SOLVED) Almost out of disk space on "/"

#5 2022-03-05 17:16:48

Re: (SOLVED) Almost out of disk space on "/"

#6 2022-03-05 17:18:56

Re: (SOLVED) Almost out of disk space on "/"

#7 2022-03-05 17:23:17

Re: (SOLVED) Almost out of disk space on "/"

#8 2022-03-05 19:51:17

Re: (SOLVED) Almost out of disk space on "/"

#9 2022-03-05 22:27:50

Re: (SOLVED) Almost out of disk space on "/"

#10 2022-03-06 02:40:52

Re: (SOLVED) Almost out of disk space on "/"

#11 2022-03-06 04:42:03

Re: (SOLVED) Almost out of disk space on "/"

Board footer