On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home tmpfs 786M 4.0K 786M 1% /run/user/464 tmpfs 786M 0 786M 0% /run/user/0 tmpfs 786M 0 786M 0% /run/user/1000
Note particularly the
/dev/sda6 40G 37G 361M 100% /
Walking through everything in / with `du -sh` shows FAR less than 37G. (like, about 5G at most)
`lsof | grep deleted` showed a handful of files owned by nscd. Stopping nscd.service showed those files gone from the `lsof` output, but no improvement in the usage reported by `df -h`.
While google was busy telling me not much more useful that the above, I spotted the
tmpfs 786M 4.0K 786M 1% /run/user/464
Which does not show up on the Desktop+Leap15.2 I'm currently writing this on. (and into which I logged on by going through lightdm; lightdm is def. running)
Further,
# ls -al /run/user/464/ ls: cannot access '/run/user/464/gvfs': Permission denied total 0 drwx------ 3 lightdm lightdm 60 Jul 27 13:29 . drwxr-xr-x 5 root root 100 Jul 27 13:21 .. d????????? ? ? ? ? ? gvfs
What is up with that gfvs dir? (yes, there was other stuff in there before, I tried deleting it all but that thing just won't move).
chmod(1), chown(1) just get 'permission denied' on that thing.
Suggestions on any of the above puzzles?
Thank you.
Michael
On poniedzia?ek, 27 lipca 2020 19:46:04 CEST Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home tmpfs 786M 4.0K 786M 1% /run/user/464 tmpfs 786M 0 786M 0% /run/user/0 tmpfs 786M 0 786M 0% /run/user/1000
Note particularly the
/dev/sda6 40G 37G 361M 100% /
Walking through everything in / with `du -sh` shows FAR less than 37G. (like, about 5G at most)
Are you using btrfs on your root partition? (Any of sudo lsblk --fs, mount or findmnt will tell you that) If you do, you probably have old snapshots clogging up your space. Try opening the filesystem snapshots window in YaST and deleting some. By the way, on btrfs filesystems, sudo btrfs fi us [mountpoint (so, / for root filesystem)] will tell you rather more than df, for example how much unallocated space is there, how much space is taken up by the actual data and metadata and such.
Regards Radosław Wyrzykowski
On 27/07/2020 19.46, Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home tmpfs 786M 4.0K 786M 1% /run/user/464 tmpfs 786M 0 786M 0% /run/user/0 tmpfs 786M 0 786M 0% /run/user/1000
Note particularly the
/dev/sda6 40G 37G 361M 100% /
Is it btrfs?
Then it is "normal".
Walking through everything in / with `du -sh` shows FAR less than 37G. (like, about 5G at most)
`lsof | grep deleted` showed a handful of files owned by nscd. Stopping nscd.service showed those files gone from the `lsof` output, but no improvement in the usage reported by `df -h`.
Nah.
While google was busy telling me not much more useful that the above, I spotted the
tmpfs 786M 4.0K 786M 1% /run/user/464
ignore it.
Which does not show up on the Desktop+Leap15.2 I'm currently writing this on. (and into which I logged on by going through lightdm; lightdm is def. running)
Further,
# ls -al /run/user/464/ ls: cannot access '/run/user/464/gvfs': Permission denied
ignore it.
Suggestions on any of the above puzzles?
Is your root btrfs? Then it is too small and you most probably have to delete some snaphots.
https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-snapper.html
https://en.opensuse.org/SDB:BTRFS
https://en.opensuse.org/Portal:Snapper
On Mon, Jul 27, Carlos E. R. wrote:
On 27/07/2020 19.46, Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home tmpfs 786M 4.0K 786M 1% /run/user/464 tmpfs 786M 0 786M 0% /run/user/0 tmpfs 786M 0 786M 0% /run/user/1000
Note particularly the
/dev/sda6 40G 37G 361M 100% /
Is it btrfs?
Then it is "normal".
Nay, ext4
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
Michael
Hello,
On Mon, 27 Jul 2020, Michael Fischer wrote:
On Mon, Jul 27, Carlos E. R. wrote:
On 27/07/2020 19.46, Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on
[..]
/dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home
(BTW: try 'df -Th' next time ;)
[..]
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
You might have stuff on that partition and the mounted other partitions over it. To check do:
# mkdir /tmp/mnt # mount -o bind /dev/sda6 /tmp/mnt
check out /tmp/mnt/home, /tmp/mnt/boot{,/efi}, /tmp/mnt/run, ...
# umount /tmp/mnt
when you're done.
HTH, -dnh
On Tue, Jul 28, David Haller wrote:
Hello,
On Mon, 27 Jul 2020, Michael Fischer wrote:
On Mon, Jul 27, Carlos E. R. wrote:
On 27/07/2020 19.46, Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on
[..]
/dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home
(BTW: try 'df -Th' next time ;)
Ah, thanks. :)
[..]
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
You might have stuff on that partition and the mounted other partitions over it. To check do:
# mkdir /tmp/mnt # mount -o bind /dev/sda6 /tmp/mnt
check out /tmp/mnt/home, /tmp/mnt/boot{,/efi}, /tmp/mnt/run, ...
Why would these "over mounts" affect the filesystem space on /dev/sda6? What exactly would I be checking for?
Cheers,
Michael
Hello,
On Mon, 27 Jul 2020, Michael Fischer wrote:
On Tue, Jul 28, David Haller wrote:
On Mon, 27 Jul 2020, Michael Fischer wrote: [..]
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
You might have stuff on that partition and the mounted other partitions over it. To check do:
# mkdir /tmp/mnt # mount -o bind /dev/sda6 /tmp/mnt
check out /tmp/mnt/home, /tmp/mnt/boot{,/efi}, /tmp/mnt/run, ...
Why would these "over mounts" affect the filesystem space on /dev/sda6? What exactly would I be checking for?
Say you have your old home with a stash of 30GB forgotten DVD-images in the "home"-directory on the root-partition from before you created the sda7 partition, copied your stuff from your old home on sda6 to sda7 but forgot to clean up. So when you now mount /dev/sda7 in /home/ it gets mounted over the contents of the "home"-directory _on_ /dev/sda6. So, 30GB "disappear" from 'du' etc. but the space is still taken (as seen via df).
bind-mounting /dev/sda6 somewhere else without then mounting sda7 in the "home"-directory on sda6 you can see if and what is on sda6 inside the "home"-directory (which should be empty).
Same goes for all mountpoints, but home seems most likely ;)
HTH, -dnh
On Tue, Jul 28, David Haller wrote:
Hello,
On Mon, 27 Jul 2020, Michael Fischer wrote:
On Tue, Jul 28, David Haller wrote:
On Mon, 27 Jul 2020, Michael Fischer wrote: [..]
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
You might have stuff on that partition and the mounted other partitions over it. To check do:
# mkdir /tmp/mnt # mount -o bind /dev/sda6 /tmp/mnt
check out /tmp/mnt/home, /tmp/mnt/boot{,/efi}, /tmp/mnt/run, ...
Why would these "over mounts" affect the filesystem space on /dev/sda6? What exactly would I be checking for?
Say you have your old home with a stash of 30GB forgotten DVD-images in the "home"-directory on the root-partition from before you created the sda7 partition, copied your stuff from your old home on sda6 to sda7 but forgot to clean up. So when you now mount /dev/sda7 in /home/ it gets mounted over the contents of the "home"-directory _on_ /dev/sda6. So, 30GB "disappear" from 'du' etc. but the space is still taken (as seen via df).
AHA! You were on the right track! (sample command is wrong though, -o bind takes a DIR - I used / - and not a device)
I'm so used to seeing /data{1,2,3,4} as my user-mounted external drives that I skipped thinking something (29G worth, it turns out) could have been being masked by the "normal" usage.
TIL. Thank you!
Michael
On 27/07/2020 23.24, Michael Fischer wrote:
On Mon, Jul 27, Carlos E. R. wrote:
On 27/07/2020 19.46, Michael Fischer wrote:
On a laptop with Leap 15.0,
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 40G 37G 361M 100% / /dev/sda2 296M 46M 251M 16% /boot/efi /dev/sda7 449G 95G 332G 23% /home tmpfs 786M 4.0K 786M 1% /run/user/464 tmpfs 786M 0 786M 0% /run/user/0 tmpfs 786M 0 786M 0% /run/user/1000
Note particularly the
/dev/sda6 40G 37G 361M 100% /
Is it btrfs?
Then it is "normal".
Nay, ext4
# mount | grep /sda6 /dev/sda6 on / type ext4 (rw,relatime,data=ordered)
Ah, ok. Then the next step is to find directory sizes on it.
Try:
du -hsx --exclude=/home --exclude=/boot/efi /*
And see what directory has most usage. Then get inside and repeat.
Or, use oter tools; baobab, for instance, if you have it installed. Even 'mc' (Midnight Commander) can do it (ctrl - space).
Typical candidates are /var/log/ or /tmp.
If you see a huge log file, before deleting it have a look inside (with less in a terminal) to find out what message is being repeated and repeated.
On Tue, Jul 28, Carlos E. R. wrote:
Ah, ok. Then the next step is to find directory sizes on it.
Already did that exercise, prowling through /tmp and /var before asking :)
Try:
du -hsx --exclude=/home --exclude=/boot/efi /*
I'll save that one for later.
Dave H. had the right guess - a dir I usually use for mounting external drives had a full 29G copy of a home dir backup hiding inside it... Never occured to me to look for such a thing because "that shouldn't happen...."
Michael
On 28/07/2020 01.27, Michael Fischer wrote:
On Tue, Jul 28, Carlos E. R. wrote:
Ah, ok. Then the next step is to find directory sizes on it.
Already did that exercise, prowling through /tmp and /var before asking :)
Try:
du -hsx --exclude=/home --exclude=/boot/efi /*
I'll save that one for later.
Dave H. had the right guess - a dir I usually use for mounting external drives had a full 29G copy of a home dir backup hiding inside it... Never occured to me to look for such a thing because "that shouldn't happen...."
I've never seen that one. Of course, I knew that a mount hides whatever would be before on that directory, but I have never done that except on purpose to see what happens, not by accident :-D
I would have thought of that after seeing the output of the command above and seeing that the partials do not add up to the total. But as a first guess, no :-D
Nor did I know about that bind mount trick to look underneath. Cute.
On Tue, 28 Jul 2020 02:20:40 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
On 28/07/2020 01.27, Michael Fischer wrote:
On Tue, Jul 28, Carlos E. R. wrote:
Ah, ok. Then the next step is to find directory sizes on it.
Already did that exercise, prowling through /tmp and /var before asking :)
Try:
du -hsx --exclude=/home --exclude=/boot/efi /*
I'll save that one for later.
Dave H. had the right guess - a dir I usually use for mounting external drives had a full 29G copy of a home dir backup hiding inside it... Never occured to me to look for such a thing because "that shouldn't happen...."
I've never seen that one. Of course, I knew that a mount hides whatever would be before on that directory, but I have never done that except on purpose to see what happens, not by accident :-D
That's why I always set the permissions of such mount-point directories to 000. Nothing can accidently write in there :) (famous last words)
I would have thought of that after seeing the output of the command above and seeing that the partials do not add up to the total. But as a first guess, no :-D
Nor did I know about that bind mount trick to look underneath. Cute.
On 28/07/2020 11.13, Dave Howorth wrote:
On Tue, 28 Jul 2020 02:20:40 +0200 "Carlos E. R." <> wrote:
On 28/07/2020 01.27, Michael Fischer wrote:
On Tue, Jul 28, Carlos E. R. wrote:
Ah, ok. Then the next step is to find directory sizes on it.
Already did that exercise, prowling through /tmp and /var before asking :)
Try:
du -hsx --exclude=/home --exclude=/boot/efi /*
I'll save that one for later.
Dave H. had the right guess - a dir I usually use for mounting external drives had a full 29G copy of a home dir backup hiding inside it... Never occured to me to look for such a thing because "that shouldn't happen...."
I've never seen that one. Of course, I knew that a mount hides whatever would be before on that directory, but I have never done that except on purpose to see what happens, not by accident :-D
That's why I always set the permissions of such mount-point directories to 000. Nothing can accidently write in there :) (famous last words)
Yes, I heard of that trick. But it doesn't help when you migrate an existing, populated, directory to a partition.
On Tue, Jul 28, Dave Howorth wrote:
On Tue, 28 Jul 2020 02:20:40 +0200 "Carlos E. R." robin.listas@telefonica.net wrote:
I've never seen that one. Of course, I knew that a mount hides whatever would be before on that directory, but I have never done that except on purpose to see what happens, not by accident :-D
That's why I always set the permissions of such mount-point directories to 000. Nothing can accidently write in there :) (famous last words)
Another neat trick. Thanks.
Michael
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David Haller -
Michael Fischer -
Radosław Wyrzykowski