I received a warning that my root volume is running out of space. Indeed

sudo ssm list

gives me

Volume                 Pool    Volume size  FS      FS size       Free  Type    Mount point                  
/dev/centos/root       centos     60.00 GB  ext4   60.00 GB    3.02 GB  linear  /                            
/dev/centos/swap       centos     31.75 GB                              linear                               
/dev/centos/lv-tmp     centos      9.00 GB  ext4    9.00 GB    8.03 GB  linear  /var/tmp                     
/dev/centos/lv_common  centos     93.00 GB  ext4   93.00 GB   86.71 GB  linear  /common                      
/dev/centos/lv_local   centos      4.00 GB  ext4    4.00 GB    3.60 GB  linear  /local                       
/dev/centos/lv_acme  centos     93.00 GB  ext4   93.00 GB   68.88 GB  linear  /acme                     
/dev/centos/home       centos    100.00 GB  ext4  100.00 GB   68.15 GB  linear  /home              

What I want is to see a view of the sizes of the directories on the affected root volume, perhaps in a tree view. I have tried a lot of different approaches, and they just don't seem to give me that information. Variations of du and df just don't seem to give the right info. I tried moving a large folder in /data to the /acme directory, and change the folder to a soft link, but it didn't make any difference for some reason. Various tools like Disk Usage Analyzer give conflicting information, k4dirstat doesn't let me select the volume, baobab gives still different conflicting information and doesn't show free space.

Any suggestions on how to see the directory sizes of a logical volume?


It turns out that the problem was that after I moved the large folder in the /data folder and replaced it with a soft link, for some reason ssm list wasn't updating its information. df shows that moving the folder did indeed have an effect. So I don't know the answer to my question yet (though I could try installing tree per al mamun's suggestion below), but as a practical matter, the problem is solved, and I will know to be suspicious of ssm in such situations.

  • 2
    As you have probably seen while googling, du is your friend here. Nevertheless, you can try the tool proposed in answers to this question on U&L, that should give you a tree with sizes. If it's of no help, in order to get helpful answers here I think you'll have to narrow your definition of "the right info".
    – fra-san
    Nov 2 '18 at 18:55
  • Try the command “du”. That’s exactly what it does.
    – mreff555
    Nov 4 '18 at 12:13

The variant you need is

du -x /

to only show the directories inside the one filesystem.

Usually people want -h to get sizes that are easier to read. And I usually pipe it through sort -h, to show the largest directory at the end:

du -xh / | sort -h

du has some limitations. It cannot see deleted files, and it cannot see directories which are "hidden" because a different filesystem has been mounted on top. If you are concerned that you might have hit a limitation, you should provide specific details (output / numbers / calculations) about your reasons for concern.


You can check directory size on different ways. use tree --du to get a tree view or use du -sh * . I am not very sure what you mean by moving from /data to /acme did not help. did it not free any disk space? You can move data to other lvs or make your root lv bigger to sovle disk space problem.


In addition to the already mentioned tree --du, it's worth pointing out that some implementations of du (e.g. the one in GNU Coreutils) have a --threshold option that prevents it from listing directories and files bigger than the specified amount (or smaller, if the threshold is prefixed with a minus sign).

To recursively list only items bigger than 1 GiB in the current directory:

$ du -ahx --threshold=1GiB .

-a tells du to list also files.
-h prints sizes in human readable format.
With the -x option, objects in different file systems are skipped. Useful when inspecting volumes that contain mount points.

There are caveats, though: du will fail to account for 1) deleted files that are still open and 2) stuff that may be "under" mount points (i.e. the content of directories that have been used as mount points). You can find more on this in the answers to How to troubleshoot disk is full.

Finally, Tracking down where disk space has gone on Linux? has a generous list of tools and commands for inspecting used space.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.