Disk SPace issues

English Install/Boot/Login
#1

Hi guys
Recently installed TW - used all defaults to installation, I have a post here about how slow my system was runninghttps://forums.opensuse.org/showthread.php/529642-System-Slow-Noticed-not-using-all-RAM-typical, but it has not been resolved, (issues include complete slowdown of system, dolphin crashes, downloads/updates fail, kde screen does not redraw etc.)but I now think the issue is disk space related (sda3). These are the default chosen by installation, I would like to know if I can resize them, and if so some advice on how- as I never done that before. thanks!
.

Kilbert@localhost:~> df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.9G   30M  7.8G   1% /dev/shm
tmpfs           7.9G   18M  7.9G   1% /run
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sda3        41G   40G   96K 100% /
/dev/sdb1       4.6T   11G  4.3T   1% /graphics3
/dev/sde1       2.7T  2.7T  4.5G 100% /workCompleted
/dev/sdj1       3.6T 1020G  2.5T  30% /Data
/dev/sdd1       3.6T  3.4T   39G  99% /graphic
/dev/sda3        41G   40G   96K 100% /var/tmp
/dev/sda3        41G   40G   96K 100% /.snapshots
/dev/sda3        41G   40G   96K 100% /var/lib/mailman
/dev/sda3        41G   40G   96K 100% /var/lib/mariadb
/dev/sda3        41G   40G   96K 100% /var/lib/mysql
/dev/sda3        41G   40G   96K 100% /var/lib/named
/dev/sda3        41G   40G   96K 100% /var/lib/pgsql
/dev/sda3        41G   40G   96K 100% /var/lib/libvirt/images
/dev/sda3        41G   40G   96K 100% /boot/grub2/i386-pc
/dev/sda3        41G   40G   96K 100% /var/cache
/dev/sda3        41G   40G   96K 100% /srv
/dev/sda3        41G   40G   96K 100% /opt
/dev/sda3        41G   40G   96K 100% /var/spool
/dev/sda3        41G   40G   96K 100% /usr/local
/dev/sdf1       4.6T  4.5T   73G  99% /Tgraphic2
/dev/sdc1       5.5T  139G  5.1T   3% /Tgraphic2
/dev/sda3        41G   40G   96K 100% /tmp
/dev/sda3        41G   40G   96K 100% /boot/grub2/x86_64-efi
/dev/sda3        41G   40G   96K 100% /var/opt
/dev/sda3        41G   40G   96K 100% /var/crash
/dev/sda3        41G   40G   96K 100% /var/lib/machines
/dev/sda3        41G   40G   96K 100% /var/log
/dev/sda1       156M  4.7M  152M   3% /boot/efi
/dev/sdi1       7.2T  4.2T  2.7T  62% /Videos
/dev/sdg1       4.6T  2.1T  2.3T  49% /Documents
/dev/sdh1       4.6T  4.0T  360G  92% /Moves
/dev/sda4       256G   14G  243G   6% /home                                                                                                                                                   
tmpfs           1.6G   32K  1.6G   1% /run/user/1000                                                                                                                                          
tmpfs           1.6G     0  1.6G   0% /run/user/0                                                                                                                                             
/dev/sdk1        15G   11G  4.2G  72% /run/media/Kilbert/2040-CF7F
#2

I recently wrote an article for this
https://en.opensuse.org/SDB:Disk_space

If you are using btrfs, check the space with:

btrfs fi usage /
#3

snapshot size is a function of age (new snapshot cost no space). try to remove anything older than say 2-3 weeks unless you have a reason not to. if you still have a problem investigate disk usage. the referenced guide seems good. do it soon - out of disk space on btrfs is not fun since deleting files does not free space.

#4

IMO you should not in the first place try to increase the size of your / file system, but try to find out why it is 100%. Something is eating space and when you increase that space it will be a matter of time before you are at 100% again.

The 100% you see here hasn’t much to do with snapshots. snapt shot do use space of course, but that is outside the file system.

Try to detect what is conspicious large. start with

cd /
du -sh *

Then look at which one is very, very large (and NOT a mounted file system of course). Let us assume it is /mnt, then the next step will be:

cd mnt
du -sh *

and so on. Also check inside such a directory what is there.
It is a try and error prcosess. Shortcuts can be to check e.g. /var/log and others that can grow out of hand.

#5

100% wrong. btrfs snapshots are by design inside filesystem and consume space. Assuming quota is enabled “btrfs qgroup show -re /” may be helpful.

#6

I bow to better to the better informed ones. But there was a time when this was not the case. df having no knowledge about snapshots.

In any case cleaning up the snapshots first is always a good idea.

#7

I tried deleting files, but as you just pointed out, it had no impact. I believe know how the drive got filled, and its legit (database). It will happen again unless I use a way larger partition. this system is only 2 weeks young, so I will try to bot and backup, but I am having trouble as there literally is no space to even run commands in the konsole (i get cannot create temp file errors)

my thought is to delete old kernels, journal to current boot only, everything in /logs & /tmp, and every old snapshot just to get some working room.
any thoughts as to why this will not be a good idea?

thanks

#8

If a database then just move it to another partition

#9

if your running a database on btrfs make sure directory is nodatacow