I'd like to list all the conterns of a directory (including subdirs) and their real size (including dir sizes). I can list them with ls, and I can see the size of each with du -sh. But is there a way to list all with du's size output?

Here is my disk space usage: Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 296K 1.9G 1% /dev/shm tmpfs 1.9G 1.6M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/fedora-root 46G 6.0G 38G 14% / tmpfs 1.9G 76K 1.9G 1% /tmp /dev/mapper/fedora-var 9.1G 8.2G 444M 95% /var /dev/mapper/fedora-home 138G 16G 115G 12% /home tmpfs 387M 12K 387M 1% /run/user/42 tmpfs 387M 16K 387M 1% /run/user/1000 I got a 95% usage on /dev/mapper/fedora-var. I don't have much stuff to be cleaned and I am not sure whether cleaning the stuff would help in this issue. I would like to expand the disk space on /var, how could I do that? thanks

I want to move an empty disc space from one partition to another. Is this possible? In the below image, I have free space under /local (/dev/sda3). I want to allocate this space to / which is on /dev/sda2. How can I do this?

Is it possible to solve the space problem below as root user? Any idea which disk/folder is full, causing installation of new software impossible? root@fba-bod-p1:/mnt/# apt install setuptools-scm Reading package lists... Error! E: Write error - write (28: No space left on device) E: IO Error saving source cache E: The package lists or status file could not be parsed or opened. root@fba-bod-p1:/mnt/# df -i Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 16483401 1476 16481925 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 6553600 356895 6196705 6% / tmpfs 16483401 1 16483400 1% /dev/shm tmpfs 16483401 4 16483397 1% /run/lock 1:2 63753378 2731153 61022225 5% /mnt/backup /dev/sda2 131072 313 130759 1% /boot /dev/sda1 0 0 0 - /boot/efi 158.39.32.194:/vol/vol_13122022_101029 31876689 96 31876593 1% /mnt/netapp1 158.39.32.196:/vol/vol_13122022_100726 31876689 2731057 29145632 9% /mnt/netapp2 tmpfs 3296680 143 3296537 1% /run/user/1000 /dev/sdc1 610469888 18352 610451536 1% /mnt/encl_vol2 /dev/sdb1 610469888 2227070 608242818 1% /home/fatima tmpfs 3296680 74 3296606 1% /run/user/1001 tmpfs 3296680 68 3296612 1% /run/user/1004 tmpfs 3296680 76 3296604 1% /run/user/1027 df Filesystem Size Used Avail Use% Mounted on tmpfs 13G 1.3G 12G 11% /run /dev/mapper/ubuntu--vg-ubuntu--lv 98G 98G 0 100% / tmpfs 63G 0 63G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock 1:2 37T 20T 18T 54% /mnt/backup /dev/sda2 2.0G 260M 1.6G 15% /boot /dev/sda1 1.1G 5.3M 1.1G 1% /boot/efi 158.39.32.194:/vol/vol_13122022_101029 17T 5.5G 17T 1% /mnt/netapp1 158.39.32.196:/vol/vol_13122022_100726 20T 20T 117G 100% /mnt/netapp2 tmpfs 13G 116K 13G 1% /run/user/1000 /dev/sdc1 37T 8.3T 27T 24% /mnt/encl_vol2 /dev/sdb1 37T 30T 5.4T 85% /home/fatima tmpfs 13G 64K 13G 1% /run/user/1001 tmpfs 13G 64K 13G 1% /run/user/1004 tmpfs 13G 68K 13G 1% /run/user/1027

We are supposed to store our ongoing projects on a rather small (~4TB) data server. Not surprisingly, it is constantly overflowing and people need to move off less recent files manually. Is there an easy (aka standard command-line) way to find out which users take up the most space in a directory? i.e. summing up the size of all files in a directory and all sub-directories belonging to each user? Edit: ideally not following symlinks

I have an issue with a virtual machine running Nextcloud and the version is Ubuntu 22.04 LTS. The system continuously indicates that the logical volume /dev/mapper/ubuntu--vg-ubuntu--lv is full (used 100%). To keep the system running, I’ve had to continuously expand the virtual disk size and extend the logical volume (using this guide ). The logical volume currently has 440GB of size, with 35GB free. Nextcloud storage and a backup disk are mounted in /mnt: Nextcloud storage /mnt/nextcloud is an iSCSI disk on a NAS, currently holding 3TB of data. The backup disk (348 GB) is also mounted in /mnt (/mnt/carpetarespaldosnas).

miusuario@nextcloud:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              3.2G  1.7M  3.2G   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  440G  387G   35G  92% /
tmpfs                               16G   28K   16G   1% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  254M  1.6G  14% /boot
/dev/sda1                          1.1G  6.1M  1.1G   1% /boot/efi
/dev/sdb1                           24T  3.1T   20T  14% /mnt/nextcloud
tmpfs                              3.2G  4.0K  3.2G   1% /run/user/1000

miusuario@nextcloud:~$ sudo du -cha --max-depth=1 /mnt 2>/dev/null
1.3G    /mnt/NCBACKUP-OLD
1002M   /mnt/NCBACKUP
4.0K    /mnt/ncdata
3.1T    /mnt/nextcloud
349G    /mnt/carpetarespaldosnas
3.5T    /mnt
3.5T    total

Since the logical volume is mounted on /, I tried various ways to get its total size to locate what was using the space, but it doesn’t show more than 30G used.

miusuario@nextcloud:~$ sudo du -cha --max-depth=1 --exclude=/mnt / 2>/dev/null
0       /lib64
28K     /dev
0       /proc
4.5G    /usr
4.0K    /opt
260M    /boot
4.0K    /media
0       /libx32
0       /sbin
0       /lib32
308K    /home
3.8G    /swap.img
1.8G    /snap
124M    /root
1.7M    /run
240K    /tmp
20G     /var
0       /bin
0       /lib
4.0K    /srv
16K     /lost+found
11M     /etc
0       /sys
30G     /
30G     total

So, I have no idea what is filling up the disk or what is actually using the space.

I am using a xfs file system at work for storing image processing data. Currently, it has around 8.8T of free space. /dev/sdh1 106T 97T 8.8T 92% While there are plans to move some of the data to tape and make room, it won't happen until next week. Currently, I keep running into "No space left on device" error quite regularly. Usually the images trasferred are around 128mb in size and they are around 100-500 of them at time. Is there anything specific to the file system that is making these ~8TB of free space unusable? On my end, I was able to verify that I can use atleast 8TB of this space using the command fallocate to create really large files of around a TB. What I am missing? Are there any obvious file-system level checks that I need to do? For your reference, here is the output of the command xfs_info for the filesystem. meta-data=/dev/sdh1 isize=256 agcount=106, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=28319810304, imaxpct=1 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 In order to reproduce the same error, I wrote a simple shell script that creates a large number of files(10k) small files (1M in size) and it fails with the following error: fallocate: temfile-7464: open failed: No space left on device Here is the output of df -i before the script is run /dev/sdh1 4531169600 648793 4530520807 1% /jumbo/K2LEGINON And after /dev/sdh1 4531169600 656256 4530513344 1% /jumbo/K2LEGINON It failed after creating around ~7500 files. Which amount to ~ 7.3G.

I'm trying to understand a significant discrepancy in disk usage between two MariaDB servers that are hosting the same application and (apparently) the same data. The two servers are entirely separate and unrelated. When I run df -h to check disk usage: Server 1: ~60G used Server 2: ~400G used To investigate further, I ran the following SQL query to check the size of each database: SELECT table_schema AS "Database", SUM(data_length + index_length) / 1024 / 1024 AS "Size (MB)" FROM information_schema.tables GROUP BY table_schema; Results: Server 1: | Database | Size (MB) | | -------- | -------------- | | information_schema| 0.20302000 | | mysql| 19.2345678| | performance_schema| 0.00000000| | myDB| 7153.45673428| | sys| 0.03561897| Server 2: | Database | Size (MB) | | -------- | -------------- | | information_schema| 0.20908965| | mysql| 21.45678765| | performance_schema| 0.00000000| | myDB| 8232.56789542| | sys| 0.03848632| As you can see, the actual data size is relatively close, yet the disk usage reported by df -h is vastly different. datadir in my.cnf points to the same location on both servers: /path/to/data Both servers are running the same MariaDB version (**11.4.2**) and have a similar setup. Running on a Red Hat 9.5 When I run SHOW variables LIKE 'log_bin%'; | Variable_name| Value | | -------- | -------------- | | log_bin| ON| | log_bin_basename| /path/to/data/mysqld-bin| | log_bin_compress| OFF| | log_bin_compress_min_len| 256| | log_bin_index| /path/to/binlog/log_bin.index| | log_bin_trust_function_creators| ON| When I run SHOW variables LIKE 'expire_logs_days%'; | Variable_name| Value | | -------- | -------------- | | expire_logs_days| 3.000000| and if I run ls -lhr /path/to/data/mysqld-bin* Engine used -> InnoDB If I run : du -ch /path/to/data/mysqld-bin* It gives me like 370G. I can see the most oldest files is 6 Mar. I think binlog files arn't properly purged. What else could be taking up disk space in /path/to/data that's not reflected in information_schema.tables? What should I check next to troubleshoot this?

I have a problem and I don't know what the problem is.

df -h
Filesystem                      Size  Used Avail Use% Mounted on
/dev/sda4                       5.0G  113M  4.9G   3% /
/dev/mapper/appsvg-lvapps       690G  539G  152G  79% /apps

When I try with the du command, it only shows 47G:

du -sh /apps
47G     /apps

I have: - Checked for deleted files still held open by processes using lsof +L1; found some deleted files, but none accounting for the large disk usage. -- it's not that - Verified presence of hidden or trash folders in /apps —- found none that explain the usage. - Verified filesystem mount point and type (xfs on /apps) -- no nested mounts inside /apps.

findmnt -R /apps
    
    TARGET SOURCE                     FSTYPE OPTIONS
    
    /apps  /dev/mapper/appsvg-lvapps xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

- Checked inode usage; inodes are plentiful, so no inode exhaustion or excessive small files. - Ran xfs_quota report on /apps to check for quotas -— no output, confirmed quotas are disabled (noquota mount option). - No bind mounts or hidden mount points found inside /apps that might cause discrepancies. - du output consistent across normal and hidden files, so no hidden large directories. I ruled out metadata mismatch (du and find + du totals match) - There are no snapshots. I suspected that the high usage might be due to data written to the mount point before the /apps filesystem was mounted, meaning files were written to the underlying directory, but since / itself shows low usage, that's not the case either. Does someone have an idea what this could be? I've already ruled out common causes like deleted files, loop devices, submounts, hidden files, etc. The discrepancy **is over 500G** which suggests something beyond the scope or can someone explain to me how is this normal behavior? I understand that differences of several gigabytes can happen, but a discrepancy of nearly 500GB -- how is that normal? UPDATE: Thanks everyone for the help, definitely an interesting issue. In the end, the problem was resolved when the application team restarted the application. I’ll keep monitoring the situation and will report back with any updates.

The disk activity monitor widget in KDE (Debian) shows constant HDD write around 12 MiB/s, when I run iotop, there is nothing that would be constantly using HDD. When I run atop, at first PAG is red and blinking but after about 3 seconds disappears, when i run free -h, I get: total used free shared buff/cache available Mem: 7.7Gi 2.2Gi 3.0Gi 1.1Gi 2.5Gi 4.2Gi Swap: 7.9Gi 0.0Ki 7.9Gi Any idea what can be causing this or how to find out? Also, i tried to clear the cache, it cleared to 1.5 Gi but after less than 5 minutes it was back to 2.5 Gi as shown above. Also i am thinking that Debian is using quite a lot of memory given that only firefox with the stackexchange window is open.

My Linux Mint system reports that /var/log occupies 165 GB of space, but all subdirectories and files within it are small (total <100 MB). This is causing the root partition (/) to fill up, preventing normal system operation Checked disk usage with sudo du -hxd1 /var/log | sort -hr – no large files found. Cleared journal logs:

sudo journalctl --vacuum-size=0
sudo rm -rf /var/log/journal/*
sudo systemctl restart systemd-journald

Looked for "deleted but open" files with

sudo lsof | grep deleted | grep '/var/log'

– no results. Verified filesystem integrity with

sudo e2fsck -n /dev/sda3

– no errors found. Checked extended attributes (getfattr, lsattr) – nothing unusual. Restarted the system multiple times – no change.

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb3       199G  193G  6.3G  97% /


sudo du -hxd1 /var/log:
165G    /var/log
4.0K    /var/log/private
12M     /var/log/apt
... (other small directories)

- What could explain the discrepancy between du and df? - How can I safely reclaim the "phantom" 165 GB in /var/log?

When mount point /dev/backboot is >70%, set to "High", and if < 70%, set to "Normal", and if there is no such mount point at all, then set to "not available". The example below works fine with two options, but I need three. Can you suggest?

- name: get usage
  command: df -k | grep -i /dev/backboot | awk '{print $5}'
  register: usage

Here, the output of registered value usage.stdout is 67% as an example:

- name: Set the value
  set_fact:
     mspace: "{{ (usage.stdout | int < 80) | ternary('Normal','High') }}"

I'm using systemd on raspberrypi machine with yocto based system. Recently I had some problems with redirecting messages to rsyslog.socket so I decided to get rid of rsyslog completely in favour of of journald. After doing so I have noticed that size of journald files is much bigger than I previously thought it would be. root@rpiDev: ~ $ journalctl -o cat > /tmp/journals-cat.txt root@rpiDev: ~ $ journalctl -o export > /tmp/journals-exp.txt root@rpiDev: ~ $ journalctl -o verbose > /tmp/journals-verb.txt root@rpiDev: ~ $ journalctl -a -m > /tmp/journals.txt ### This is what I need! root@rpiDev: ~ $ journalctl -a -m -o verbose > /tmp/journals-everything.txt root@rpiDev: ~ $ du -sh /tmp/journals* /var/log/journal/ ; journalctl --disk-usage 468.0K /tmp/journals-cat.txt 15.7M /tmp/journals-everything.txt 4.7M /tmp/journals-exp.txt 4.9M /tmp/journals-verb.txt 2.3M /tmp/journals.txt 41.0M /var/log/journal/ Archived and active journals take up 12.5M on disk. Comparing the sizes it looks like binary files created by journald are much bigger than merged (-m) logs. What I actually need is what is inside /tmp/journals.txt. **Question:** Is it possible to reduce amount of stuff stored by journald in it's binary files to what I noticed when running journalctl -a -m? In other words: can I disable storing all of the information that is not important to me and use journald just as I would syslog? My problem can be solved by disabling permanent storing of journald logs and forwarding them to syslog, but maybe it is possible without bringing back rsyslog? EDIT: Parameters mentioned by some users do not help me here. - Using SystemMaxUse= and RuntimeMaxUse= only sets the maximum size of the files stored- I can have smaller files with the same amount of not needed info and therefore even less actual logs. - Using MaxLevel...= sets the maximum log level stored in the journal. That is also not what I need here. EDIT2: My solution: I have decided to store logs in syslog (I use rsyslog).
In my journald.conf I have set Storage=volatile and used SystemMaxUse=64M and RuntimeMaxUse=64M to limit disk usage by journald.
I also enabled ForwardToSyslog=yes so now I have my old syslog solution working and I'm also able to view runtime journald logs.

I want to see how many files are in subdirectories to find out where all the inode usage is on the system. Kind of like I would do this for space usage du -sh /* which will give me the space used in the directories off of root, but in this case I want the number of files, not the size.

On our RHEL 7.9 systems, we have noticed some strange behavior. Each machine has 4 disks, each with an 8TB capacity, but we are only using about 1.9TB on a partition. What doesn’t make sense is that the Use% value appears incorrect. As shown below, the usage of /data/sde is reported as 15%, but the actual used space is only 267MB, while the /dev/sdd1 partition size is 1.9TB. Filesystem Size Used Avail Use% Mounted on /dev/sdd1 1.9G 267M 1.6G 15% /data/sde Could this be related to how the partition was created, or is there something else causing this discrepancy? df -h Filesystem Size Used Avail Use% Mounted on /dev/sdg1 1.9G 5.7M 1.8G 1% /data/sdh /dev/sdf1 1.9G 5.7M 1.8G 1% /data/sdg /dev/sdb1 1.9G 44M 1.8G 3% /data/sdc /dev/sdd1 1.9G 267M 1.6G 15% /data/sde

I have created a Vm in Azure with Oracle Linux 9. I have selected a 128G disk but when I see the size of the partitions I see that it was not fully used. [root@oraclelinux ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 128G 0 disk ├─sda1 8:1 0 800M 0 part /boot ├─sda2 8:2 0 28.7G 0 part │ ├─rootvg-rootlv 252:0 0 18.7G 0 lvm / │ └─rootvg-crashlv 252:1 0 10G 0 lvm /var/crash ├─sda14 8:14 0 4M 0 part └─sda15 8:15 0 495M 0 part /boot/efi sdb 8:16 0 32G 0 disk └─sdb1 8:17 0 32G 0 part /mnt I need to add all extra space available to the rootvg-rootlv partition. I haven't found in the Azure documentation a way. How is it possible to add more space to the partition with mount point / ? [root@oraclelinux ~]$ parted /dev/sda print Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 205520896 blocks) or continue with the current setting? Fix/Ignore? ignore Model: Msft Virtual Disk (scsi) Disk /dev/sda: 137GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 1049kB 5243kB 4194kB bios_grub 15 5243kB 524MB 519MB fat16 EFI System Partition boot, esp 1 525MB 1364MB 839MB xfs 2 1364MB 32.2GB 30.8GB lvm

I would like to know how much space is used my LaTeX install. I tried to do with apt but I am not sure it's possible. What I would like to do is to have a command like apt-cache list --show-install-size texlive* outputing 128 MB and of course the show-install-size doesn't exist.

I block copied a 50 GB linux partition (almost full, 92% used), from a disk which had started to have some errors to a 666 GB partition of a 750 new hard drive using ddrescue -v -d -r 3 -f /dev/... /dev/... After using grub I was able to boot from the new hard drive without any noticeable problems. While I somehow expected that I might need to resize the result of my copying, now both gparted and df report that my new drive is close to being full, however in different ways: gparted says that 660 GB have been used out of 666 GB available in the partition, and df claims the partition has 41 GB in use out of a total of 47 GB. I don't understand what is wrong, nor how to interpret the vastly different sizes of /dev/sda1/ by gparted and df. I am lost and would appreciate suggestions about how one can recover the use of the space in the new disk which I expected to be more than 90% free, even after putting the contents of the old.

I defined a new samba mount in an ubuntu VM via /etc/fstab

//x.x.x.x/share  /share  cifs  credentials=/.smbcreds,uid=1000,gid=1000,vers=3.0  0  0

With this I get the following output from df -h

filesystem       Size   Used  Avail  Use%  Mounted On
//x.x.x.x/share  5.0G   79M   5.0G   2%    /share
...

This is a ZFS share on the host and I am using samba to expose it here. I would expect to see about 12TB of free space, which is what I see if I run df -u on the samba host. Running du -f --max-depth=1 in the ubuntu VM reports this:

2.2T   /share
...

Which is the correct usage for the mount. Ultimately I am having issues where services are trying to write files to the mount that are larger than the total reported filesystem space and they fail since they do a check on available space before writing.

Have installed Trisquel 11.0 LTS. It is a desktop environment based on MATE 1.26 and Ubuntu 22.04 LTS. Have seen there exists the program Disk Usage Analyzer. But where can I find it? I want to include it in my Main Menu, but cannot find it. I went to System > Control Center > Main Menu. But could not find it in Menus > Applications or Menus > System. Used to call baobab in the command line, but now its name has changed. Disk Usage Analyzer analyses your disk usage through a graphical tool. Copyrighted by Fabio Marzocca and MATE developers.