Re: solution to / full
Hi,
On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev 126G 0 126G 0% /dev
> tmpfs 26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G 966M 96% /
> tmpfs 126G 15M 126G 1% /dev/shm
> tmpfs 5.0M 4.0K 5.0M 1% /run/lock
> /dev/nvme0n1p6 267M 83M 166M 34% /boot
> /dev/nvme0n1p1 511M 5.8M 506M 2% /boot/efi
> /dev/nvme0n1p3 9.1G 3.2G 5.5G 37% /var
> /dev/nvme0n1p5 1.8G 14M 1.7G 1% /tmp
> /dev/nvme0n1p7 630G 116G 482G 20% /home
This is an excellent illustration of why creating tons of partitions
like it's 1999 can leave you in a difficult spot. You are bound to
make poor guesses as to what actual size you need, which leads later
situations where some partitions are hardly used while others get
full.
Ideally you'd use LVM, or filesystems that do volume management like
btrfs or zfs, so you can start small and adjust later based on your
needs. If that seems daunting, I think the user is not ready for
complex partitioning and would almost always be best off just using
one big / for everything.
It is difficult to say if you have things installed that you don't
need, because we don't know your needs nor what you have installed!
If you have many old kernel packages installed these can take up a
lot of space and it's probably safe to purge all but the newest one
and the one before it (and the one you're currently using).
$ dpkg -l | grep linux-image
for a quick overview.
> # ncdu -x
> --- /
> --------------------------------------------------------------------------
> 17.4 GiB [##########] /usr
>
> 3.2 GiB [# ] /opt
3GiB seems quite large for /opt so you probably have some manually
installed things in there that you might no longer need.
> What is the best solution so far?
Here's how I'd get out of this. These steps are off the top of my
head and though I have done them hundreds of times before I may not
have remembered exactly the correct syntax so please research every
step and understand what they are doing.
1. Install lvm2 package
# apt install lvm2
2. Boot into single user mode¹ and shrink /dev/nvme0n1p7 (/home) to
about 150G down from its ridiculous current size of 630G.
# umount /home
I'm assuming you're using ext4 filesystem there so it would be:
# resize2fs -p /dev/nvme0n1p7 145g
It will probably tell you to do e2fsck first; if so do that then
repeat the resize2fs command.
The choice of 145g was on purpose because next we'll use parted
to shrink the actual partition and we don't want to be doing any
mathematics. So next step is to shrink the partition, then grow
the filesystem again to its maximum for the partition it's in.
# parted /dev/nvme0n1 resizepart 7 150g
# resize2fs -p /dev/nvme0n1p7
3. Create a /dev/nvme0n1p8 in the newly-created space.
# parted /dev/nvme0n1
(parted) print
(parted) mkpart
(accept all the default suggestions as it will just put it at the
end)
4. Turn that into an LVM Physical Volume (PV)
# pvcreate /dev/nvme0n1p8
5. Create an LVM Volume Group (VG) that uses that PV. Pick any name
you like for "myvg".
# vgcreate myvg /dev/nvme0n1p8
6. Create a new Logical Volume (LV) that you'll use for what is
currently /opt. You currently have about 3.2G in there and I'll
assume you didn't want to delete any of it so I will assume
making it 5GiB will work and allow for some growth there.
# lvcreate -L5g /dev/myvg/opt
# mkfs.ext4 /dev/myvg/opt
7. Temporarily mount new filesystem somewhere.
# mkdir -vp /mnt/newopt
# mount /dev/myvg/opt /mnt/newopt
8. Copy all the data from current /opt to /mnt/newopt then switch
them around
# tar -C /opt -Spcf - . | tar -C /mnt/newopt -xvf -
# mv -v /opt /opt.old
# mkdir -vp /opt
# umount /mnt/newopt
# rmdir /mnt/newopt
Note the >> on this next command to append to — NOT overwrite —
/etc/fstab!
# cat <<EOF >> /etc/fstab
/dev/myvg/opt /opt ext4 noatime 0 2
EOF
# mount -v /opt
(at this point if you are at all unsure about what you're doing,
make sure you have a backup of /opt.old)
# rm -vr /opt.old
At this point you have moved what was in /opt into LVM in the
space freed up by shrinking your /home. This will have freed up
about 3GiB from /.
9. Reboot and hope you did everything correctly.
I chose /opt because it was a simple example and probably not
catastrophic to the running of your system if you mess it up. It is
a very small win, though. You can easily do the same procedure to
move your current /usr/share and /usr/local into there, moving
another 8GiB or so away from /. You could also just put whole of
/usr into LVM. This works fine as long as the /usr filesystem is
mounted by the initramfs which is what happens by default.
Ultimately I personally would move every partition into LVM and then
repurpose each partition as an LVM PV as I went, adding the PV to
the volume group. Eventually the aggregate space of all the
partitions /dev/nvme0n1p3 (currently /var), /dev/nvme0n1p7
(currently /home) and /dev/nvme0n1p8 (proposed new PV) would be
available to LVM.
You can't put /boot/efi in LVM and it's not worth putting /boot in
there in my opinion. In your case I expect I'd stop after putting
/opt, /usr/local, /usr/share, /var and /home in LVM.
If you don't like LVM then you can do the same thing with btrfs
after shrinking /dev/nvme0n1p7 and creating /dev/nvme0n1p8. zfs is a
bit more inflexible and not well-suited to this kind of
reorganisation of an existing system.
Finally, if you are terrified of doing this sort of thing and don't
mind gross and ugly hacks, you could just move /opt/, /usr/local and
/usr/share into somewhere under /home and symlink them back to where
they should be.
Cheers,
Andy
¹ For the example of /opt it's highly likely that you could do this
without dropping to single user mode. The main point is that you
won't be able to completely remove and unmount things while there
is a process running from it; neither is it a good idea to be
copying data files that may be currently in use by running
processes. You are likely to want to go on and do more of this, so
I am advising doing it in single user mode.
If you know what you're doing you can find the particular running
processes, kill them, and move around all of /opt, /home, /var,
/usr/local and /usr/share without rebooting or dropping down to
single user, but explaining how to do that probably makes this
email four times longer and a lot more error-prone.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Reply to: