# What's going on with disk space? **URL:** \ **Category:** Rocky Linux Help & Support\ **Created:** [September 16, 2022, 8:19am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265 "2022-09-16T08:19:54Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 16, 2022, 8:19am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/1 "2022-09-16T08:19:55Z")
After facing a surprising _no space left on device_, I issued a `df -h`, whose result follows. ```auto Filesystem Size Used Avail Use% Mounted on devtmpfs 63G 0 63G 0% /dev tmpfs 63G 0 63G 0% /dev/shm tmpfs 63G 18M 63G 1% /run tmpfs 63G 0 63G 0% /sys/fs/cgroup /dev/nvme0n1p5 64Z 64Z 42G 100% / tmpfs 13G 60K 13G 1% /tmp /dev/nvme0n1p2 96M 25M 72M 26% /boot/efi /dev/nvme0n1p6 64Z 64Z 19G 100% /var tmpfs 9,6M 340K 9,3M 4% /var/log tmpfs 9,6M 0 9,6M 0% /var/tmp /dev/nvme0n1p7 64Z 64Z 806G 100% /home tmpfs 13G 12K 13G 1% /run/user/42 tmpfs 13G 4,0K 13G 1% /run/user/1000 ``` To me the _Avail_ column values are realistic, but the _Size_ and _Used_ ones are driving me nuts. On the root of the file system I issued the following command. `for d in $(ls) ; do du -sh $d 2>/dev/null; done` The output follows. ![ss](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/2X/e/e8069f1742e5380110224f523720f5c00ed6875c.png) What am I missing?! 😟 Thanks in advance! Andrea ---
**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\ **Post date:** [September 16, 2022, 8:33am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/2 "2022-09-16T08:33:41Z")
> [@AppLEaDaY](#): > > `/dev/nvme0n1p5 64Z 64Z 42G 100% /` Sometimes processes can block disk space, until the service/process has been restarted. I’ve had such situations like that. Have you tried restarting the server to see if that 42GB becomes available? ---
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 16, 2022, 9:01am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/3 "2022-09-16T09:01:52Z")
Just rebooted. Nope. ![ss](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/2X/b/b935948099c7fc57e19ec6f5921f73bab792600f.png) It is frustrating how likely is that I find myself ignorant after tons of Linux installations made. I hope I’ll get out of this nightmare soon. Thanks anyway! Andrea ---
**Author:** ![felfert](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/felfert/32/2259_2.png) [@felfert](https://forums.rockylinux.org/u/felfert)\ **Post date:** [September 16, 2022, 9:07am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/4 "2022-09-16T09:07:29Z")
Theres something else: It shows /dev/nvme0n1p5 and /dev/nvme0n1p6 to have 64 \*`Zeta`\*bytes. That cant’t be true, so I suspect that the partition table of your NVME disk is somehow corrupted. Later: Maybe not the partition table, but definitively the filesystem (superblock?). So you should check, if `lsblk` and `fdisk -l` report correct partition sizes. ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [September 16, 2022, 9:11am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/5 "2022-09-16T09:11:16Z")
First, there is a bit simpler ‘du’: `sudo du -d 1 -hx /` The sizes shown by df look fascinating. What does `lsblk` show? PS. Please, no bitmap screenshots. ---
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 16, 2022, 9:41am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/6 "2022-09-16T09:41:12Z")
`lsblk` gives ```auto NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3,7T 0 disk ├─sda1 8:1 0 16M 0 part └─sda2 8:2 0 3,7T 0 part sdb 8:16 0 5,5T 0 disk └─sdb1 8:17 0 5,5T 0 part nvme0n1 259:0 0 1,8T 0 disk ├─nvme0n1p1 259:1 0 450M 0 part ├─nvme0n1p2 259:2 0 100M 0 part /boot/efi ├─nvme0n1p3 259:3 0 16M 0 part ├─nvme0n1p4 259:4 0 930,1G 0 part ├─nvme0n1p5 259:5 0 50G 0 part / ├─nvme0n1p6 259:6 0 20G 0 part /var └─nvme0n1p7 259:7 0 862,4G 0 part /home ``` and `fdisk -l` gives ```auto Disk /dev/nvme0n1: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 3F3A7ADB-96DC-4651-82E7-6C2869DAC50F Device Start End Sectors Size Type /dev/nvme0n1p1 2048 923647 921600 450M Windows recovery environment /dev/nvme0n1p2 923648 1128447 204800 100M EFI System /dev/nvme0n1p3 1128448 1161215 32768 16M Microsoft reserved /dev/nvme0n1p4 1161216 1951746047 1950584832 930,1G Microsoft basic data /dev/nvme0n1p5 1951746048 2056603647 104857600 50G Linux filesystem /dev/nvme0n1p6 2056603648 2098546687 41943040 20G Linux filesystem /dev/nvme0n1p7 2098546688 3907029134 1808482447 862,4G Linux filesystem Disk /dev/sda: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 1CECEDC5-FE1E-4007-A62B-767B8BA272DB Device Start End Sectors Size Type /dev/sda1 34 32767 32734 16M Microsoft reserved /dev/sda2 32768 7814033407 7814000640 3,7T Microsoft basic data Partition 1 does not start on physical sector boundary. Disk /dev/sdb: 5,5 TiB, 6001174511616 bytes, 11721043968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 3958AA31-F16B-4C5A-BCFF-304E97F2E3A3 Device Start End Sectors Size Type /dev/sdb1 2048 11721041919 11721039872 5,5T Microsoft basic data ``` Can you see any outstanding explanation there? So far I’m puzzled… Andrea ---
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 16, 2022, 9:46am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/7 "2022-09-16T09:46:11Z")
Below the output of `du -d 1 -hx /`. ```auto |4,0K|/opt| |---|---| |8,0K|/media| |16K|/lost+found| |4,0K|/srv| |47M|/root| |12K|/mnt| |206M|/boot| |4,4G|/usr| |34M|/etc| |4,7G|/| ``` I respect the request of avoiding screenshots, though, as you can see, in this case upon pasting I get pipes as separation characters and I don’t know why. That was the reason why I resorted to screenshots. Thanks! Andrea ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [September 16, 2022, 9:56am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/8 "2022-09-16T09:56:42Z")
> [@AppLEaDaY](#): > > as you can see, in this case upon pasting I get pipes as separation characters and I don’t know why. Fascinating. The forum software thinks the content is a table and adds “table elements”: | 4.3G | /var | | --- | --- | | 16K | /lost+found | | 4.0K | /mnt | Which one sould probably edit to: | Size | Path | | --- | --- | | 4.3G | /var | | 16K | /lost+found | | 4.0K | /mnt | However, if the paste has other than tab-separated lines, you get: $ sudo du -d 1 -hx / 4.3G /var 16K /lost+found 4.0K /mnt These communication issues do not help with the actual problem. ---
**Author:** ![felfert](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/felfert/32/2259_2.png) [@felfert](https://forums.rockylinux.org/u/felfert)\ **Post date:** [September 16, 2022, 10:03am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/9 "2022-09-16T10:03:23Z")
So your partitions look ok. A hunch (hopefully not true): In the partition table, a Microsoft partition is on /dev/nvme0n1p4, just before the corrupted linux partitions. So: Could it be this partition was bigger in the past, and when you installed Rocky, you resized the partition but forgot to resize the filesystem (NTFS?) in it and you ran Windows before those strange errors did occur? If yes: You data is most likely overwritten (lost) and you know at least the reason why. If no, I’m out of ideas unfortunately. ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [September 16, 2022, 11:02am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/10 "2022-09-16T11:02:47Z")
> [@felfert](#): > > Could it be this partition was bigger in the past, and when you installed Rocky, > you resized the partition but forgot to resize the filesystem (NTFS?) in it and you > ran Windows before those strange errors did occur? If that has happened and filesystems are messed up, then `fsck` should be able to tell that things are not ok? ---
**Author:** ![felfert](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/felfert/32/2259_2.png) [@felfert](https://forums.rockylinux.org/u/felfert)\ **Post date:** [September 16, 2022, 11:10am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/11 "2022-09-16T11:10:35Z")
> [@jlehtone](#): > > If that has happened and filesystems are messed up, then `fsck` should be able to tell that things are not ok? Normally, I would say yes, on the other hand **IF** they are really corrupted - prediction of fsck behavior is more like a guessing game 😉 ---
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 16, 2022, 1:03pm UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/12 "2022-09-16T13:03:50Z")
`/dev/nvme0n1p4` is simply the partition I made to install Windows there. I partitioned the entire SSD disk from scratch. Windows was installed first and then I installed Rocky Linux in the space I left for it, presumably yet not partitioned at the time I installed Windows. `/dev/nvme0n1p5`, `/dev/nvme0n1p6` and `/dev/nvme0n1p7` do have the size I could expected from there after partitioning. As for the _no space left on device_, it turned out it was probably due to space exhaustion in `/var/tmp`, that I configured as a temporary file system in RAM, but unfortunately with too much limitation in size - I could easily mend for it, once discovered the problem. Elsewhere, in spite of the 100% usage indication, I could successfully create huge dummy files with dd and no error raised. I’m pretty much ignorant concerning such issues, but could it be just a SSD-related issue? Maybe something related to the way the SSD disk is controlled? I remember a setting in the BIOS configuration… Thanks! Andrea ---
**Author:** ![AppLEaDaY](https://avatars.discourse-cdn.com/v4/letter/a/41988e/32.png) [@AppLEaDaY](https://forums.rockylinux.org/u/AppLEaDaY)\ **Post date:** [September 21, 2022, 7:24pm UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/13 "2022-09-21T19:24:34Z")
2022-09-21 For some reason I decided to install the system again, in the same partitions seen before. Mysteriously now the behavior is normal, as far as sizes are concerned. ---
**Author:** ![hunter86\_bg](https://avatars.discourse-cdn.com/v4/letter/h/f08c70/32.png) [@hunter86\_bg](https://forums.rockylinux.org/u/hunter86_bg)\ **Post date:** [September 22, 2022, 7:29pm UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/14 "2022-09-22T19:29:21Z")
First of all, when using ‘du’ use the ‘-x’ switch . When a process uses a file, in /proc/{pid}/fd there is a “reference” to that file. So imagine that an app writes to a log that is never rotated and that becomes 30G. Then an unexperienced user would ‘rm -f’ that log. Yet, the space won’t be released until the process is dead. In such scenarios use ‘lsof’ and search for deleted files. Once you find it, go to /proc/{pid}/fd/ and use ‘truncate -s 0 {number of the fd}’ to release the space without restarting the application. P.S.: You can also copy deleted files by ‘cp {number of fd} /{new\_destination}’. ---
**Author:** ![brian](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/brian/32/5777_2.png) [@brian](https://forums.rockylinux.org/u/brian)\ **Post date:** [August 25, 2023, 3:39am UTC](https://forums.rockylinux.org/t/whats-going-on-with-disk-space/7265/15 "2023-08-25T03:39:30Z")