On 3/1/23 05:35, lina wrote:
Hi,
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
# ncdu -x
--- /
--------------------------------------------------------------------------
17.4 GiB [##########] /usr
3.2 GiB [# ] /opt
16.5 MiB [ ] /etc
7.3 MiB [ ] /root
What is the best solution so far?
I have done some purging already.
:/usr# du -sh *
742M bin
4.0K games
260M include
8.1G lib
36M lib32
4.0K lib64
140M libexec
33M libx32
3.4G local
53M sbin
4.6G share
215M src
Thanks,
I put the vast majority of my user data on a file server. I keep my
FOSS system images small enough to fit onto "16 GB" devices (USB flash,
SDHC, HDD, SSD, etc.), to facilitate portability, migration, imaging
time, and image storage. I am the sole user of my systems, and keep my
home directory inside the root filesystem. Root drive space is an
ongoing issue for me.
I use apt-get(8) to update/ upgrade/ dist-upgrade my Debian systems on a
monthly cycle. Afterwards, I run 'apt autoremove' and 'apt clean'. I
install, remove, and/or upgrade packages at random intervals in between.
Doing autoremove and clean today:
2023-03-01 10:40:15 root@laalaa ~
# df /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/sdb3_crypt 12084M 8486M 2964M 75% /
2023-03-01 10:40:18 root@laalaa ~
# apt autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2023-03-01 10:40:25 root@laalaa ~
# apt clean
2023-03-01 10:40:30 root@laalaa ~
# df /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/sdb3_crypt 12084M 8418M 3031M 74% /
So, 68E+6 bytes reclaimed.
When I want to clean deeper, I use a pipeline with du(1), sort(1),
head(1) to find likely candidates:
2023-03-01 10:44:39 root@laalaa ~
# du -mx / | sort -rn | head -n 20
8418 /
5113 /usr
3158 /usr/lib
1993 /home
1893 /home/dpchrist
1578 /usr/share
1247 /var
973 /var/log
970 /usr/lib/x86_64-linux-gnu
945 /var/log/journal/0ef88c23a8cf40c883469b3b34665f5f
945 /var/log/journal
790 /home/dpchrist/.cache
729 /home/dpchrist/.cache/thumbnails
664 /usr/lib/modules
612 /home/dpchrist/.thunderbird
596 /home/dpchrist/.thunderbird/dpchrist
396 /home/dpchrist/.cache/thumbnails/large
334 /usr/share/locale
333 /home/dpchrist/.cache/thumbnails/normal
330 /home/dpchrist/.thunderbird/dpchrist/Mail/Local
Folders/dpchrist-mail.sbd
I know that /home/dpchrist/.cache/thumbnails is managed by the Xfce
desktop (notably thunar(1)). I believe I can remove the contents by
hand without damaging my installation:
2023-03-01 10:52:34 root@laalaa ~
# ls -l /home/dpchrist/.cache/thumbnails/normal | head -n 3
total 339876
-rw-r--r-- 1 dpchrist dpchrist 26496 Sep 22 10:57
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.png
-rw-r--r-- 1 dpchrist dpchrist 6273 Jun 2 2022
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.png
2023-03-01 11:01:41 root@laalaa ~
# find /home/dpchrist/.cache -name '*.png' -delete
2023-03-01 11:01:50 root@laalaa ~
# du -mx / | sort -rn | head -n 20
7692 /
5113 /usr
3158 /usr/lib
1578 /usr/share
1266 /home
1247 /var
1167 /home/dpchrist
973 /var/log
970 /usr/lib/x86_64-linux-gnu
945 /var/log/journal/0ef88c23a8cf40c883469b3b34665f5f
945 /var/log/journal
664 /usr/lib/modules
612 /home/dpchrist/.thunderbird
597 /home/dpchrist/.thunderbird/dpchrist
334 /usr/share/locale
330 /home/dpchrist/.thunderbird/dpchrist/Mail/Local
Folders/dpchrist-mail.sbd
330 /home/dpchrist/.thunderbird/dpchrist/Mail/Local Folders
330 /home/dpchrist/.thunderbird/dpchrist/Mail
316 /usr/lib/modules/5.10.0-21-amd64
316 /usr/lib/modules/5.10.0-20-amd64
So, 726E+6 bytes reclaimed.
Looking at /home/dpchrist/.thunderbird:
2023-03-01 11:08:02 root@laalaa ~
# du -sm /home/dpchrist/.thunderbird/*
1 /home/dpchrist/.thunderbird/6rfpmfz4.default
1 /home/dpchrist/.thunderbird/Crash Reports
1 /home/dpchrist/.thunderbird/Pending Pings
596 /home/dpchrist/.thunderbird/dpchrist
1 /home/dpchrist/.thunderbird/installs.ini
16 /home/dpchrist/.thunderbird/otrar7nk.default-default
1 /home/dpchrist/.thunderbird/profiles.ini
I have a basic understanding of Thunderbird and its data directories.
6rfpmfz4.default, otrar7nk.default-default, and dpchrist are Thunderbird
profile directories. 6rfpmfz4.default was likely created the first time
I ran Thunderbird. otrar7nk.default-default was likely created when I
connected to my mail server. I restored dpchrist from backup when I
migrated from my previous daily driver computer, I configured
Thunderbird to use it, and it now contains my live profile and e-mail
files. If I want to touch any of those profile directories, or their
contents, I must use Thunderbird -- rm(1) is a bad idea (been there,
done that).
My approach to ~/.thunderbird applies to every other directory on the
system -- you have to know what application or service uses that
directory, and the proper way to do housekeeping.
Of course, it is wise to backup, archive, and/or image regularly; and
especially before going on a cleaning rampage.
I keep a plaintext sysadmin log file with console sessions for every
computer.
I check in the sysadmin log and all system configuration files to a
networked configuration management system (cvs(1)).
I think your best answer is to do a backup, wipe, fresh install, restore
cycle, taking into account the usage information you posted. I would
partition the SSD with 1E+9 byte EFI, 1E+9 byte ext4 boot, 1E+9 byte
random key encrypted swap, and 28E+9 byte LUKS extr4 root (e.g. for "32
GB" devices). When there is a non-trivial amount of space left on the
device, I typically make a LUKS ext4 "scratch" partition/ filesystem.
Your usage would indicate "home".
David
