I have a one Terabyte external hard disk drive that I intend (should have done this long ago) to use for backups, and I have done a lot of experimenting to get my mind round it. When I looked again just now at its properties in the Propertymenu item in the desktop graphics listing I was shocked to see that about a third of it is used up. Then I looked on the command line and got this:

[root@localhost]/home/Harry# du -cs /run/media/Harry/CA6C321E6C32062B
167785742   /run/media/Harry/CA6C321E6C32062B
167785742   total
[root@localhost]/home/Harry# ls -alh /run/media/Harry/CA6C321E6C32062B
total 4.2M
drwx------  1 Harry Harry 4.0K Nov 18 15:15 .
drwxr-x---+ 3 root  root    60 Nov 21 14:14 ..
drwx------  1 Harry Harry 4.0K Oct 22  2013 2014-01-07
drwx------  1 Harry Harry 4.0K Sep 22 20:12 2014-09-22
drwx------  1 Harry Harry 4.0K Sep 23 19:56 2014-09-23
drwx------  1 Harry Harry 4.0K Sep 23 19:56 2014-09-24
drwx------  1 Harry Harry 4.0K Sep 25 19:18 2014-09-25
drwx------  1 Harry Harry 4.0K Sep 25 19:18 2014-09-26
drwx------  1 Harry Harry 4.0K Sep 27 23:33 2014-09-27
drwx------  1 Harry Harry 4.0K Sep 28 19:12 2014-09-28
drwx------  1 Harry Harry 4.0K Oct  7 20:00 annals
-rw-------  1 Harry Harry   30 Apr 23  2013 autorun.inf
drwx------  1 Harry Harry    0 Oct 12 16:54 GPS
drwx------  1 Harry Harry    0 Nov 18 15:15 System Volume Information
-rw-------  2 Harry Harry 4.2M Apr 17  2013 TOSHIBA STOR.E ALU 2S 2.5.pdf

I have seen several sites that "explain" the difference, and give several different and rather confusing answers, none that would help me to recover the space.

I looked at this a little while ago and "deleted" a huge trash folder, with rm I think, perhaps that is part of the problem.

To add to this, after writing the above, and an internet search I have used this command: ncdu /run/media/Harry/CA6C321E6C32062B, and the result is in this image. I also tried this

[root@localhost]/home/Harry# baobab /run/media/Harry/CA6C321E6C32062B
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)

(baobab:15557): dconf-WARNING **: failed to commit changes to dconf: The connection is closed

... and it produced this image. Moving this mouse pointer to the inner ring produced the label Annals 171.8 GB, but I can't get that on to the image.

this image

Please is there a way to recover this extra space apparently occupied by an Annals directory? I have no idea where that came from. Please treat me as a complete beginner as far as this is concerned.

  • You seem to be asking two different questions: 1) How to "recover" space wasted due to block size. The answer to that is you don't. And 2) How to recover space used by a large directory you have no idea where it came from. That is quite obvious: delete it. – psusi Nov 21 '14 at 23:55

Why not just delete the annals directory?

# rm -r /run/media/Harry/CA6C321E6C32062B/annals

Note: It looks like it's been in a Windows machine as it has a System Volume Information directory. This means it's probably NTFS? If that's the case, then you'd be better off formatting it with a more *nix friendly filesystem.

Of course, that assumes you don't want to keep anything that's on it. If you do, copy that off the disk first, then format it.


Your first bet if you want to keep/fix most of the content: Connect it to a real windows box, and run chkdsk /f /r upon that drive

Warning: This may take several hours.
Check e.g. http://technet.microsoft.com/en-us/magazine/ee872425.aspx for the usage.

As the used filesystem was not specified, I'm also assuming NTFS due to the obvious autorun.inf file and System Volume Information folder.
(Hint: The TOSHIBA STOR.E ALU 2S also came preformatted with NTFS)

For the other part of your question, a difference in totally used space can either come from a damaged filesystem, or from open filehandles. The latter could be easily observed by a difference from du -sm /run/media/Harry/CA6C321E6C32062B and
df -m /run/media/Harry/CA6C321E6C32062B outputs, and compared the used space from df to the du output, should be pretty close to each other.

You also didn't specify how you conclude that more then 30% of the drive is used?


If I am understanding the question correctly, the problem is that you are reading and interpreting the data incorrectly. The size shown by 'ls' is the size of the directory listing, not the size of all the files contained in the directory.

Try this:

Grab a small box. Put a couple books or other large/heavy objects in it. Now take a small piece of paper and write "box of stuff" on it. Now weight the box. Then weigh the piece of paper separately. Are they the same? Unless you used some very heavy paper, it is not likely. The paper (and the writing telling you what is in the box, but NOT the box itself) probably weighs so little that the scale will not even register it.

A directory listing is much the same. It is not the contents of the directory; I is only a label to tell you what is in it. And that is what 'ls' is reporting: The size of only the label. The command 'du', on the other hand, is telling you how much the box and everything in it weighs.

So why is it 4.0K? Well, imagine if you have many boxes, and each the same size. For many small items--such as a paper listing of the items in the other boxes--you can fit many of them in a single box. But for very large items/the items themselves, you may need more than one box to store them all. Again, a file system is much the same. It divides the total disk in to smaller chunks, called "blocks". For very small items, you only need one box. For very big items, you may need more than one. In this case, your example indicates the block size of the disk is 4.0K. So as long the list of all the files fits inside 4.0K, it will not use another "box"/"block". The entire listing fits in a single block, whether or not the actual contents of the files do. Since this is the minimum size allocated for each block, it will always be 4.0k for anything equal to or less than 4.0K. Once the listing exceeds 4.0K, it will allocate another 4.0K block, giving a total size of 8.0K. It will not allocate another block now until the total size exceeds 8.0K. And so on.

If you wonder why 'ls' does not list the total size used by the directory data and the total of all the files within it, that is simple: It would have to calculate the size of every item every time you did an 'ls' command. Imagine if you did 'ls -al /' -- It would have to calculate the total size of your entire 1TB drive ever time you wanted to list "/". But it would have to examine every file in the file system to figure out which files are symbolic links, which are hard links, which are mount points, and so on, in order to adjust the total accordingly.

For example, if you have a 4MB drive (yes, that is tiny by modern sizes) partitioned in to four 1MB partitions. Partition 1 is the root "/", partition 2 is the swap space, partition 3 is mounted at "/some/deep/nested/path", and partition 4 is "/home". What should "ls -al /" report? The total size of the "/" partition (1MB) or the total size of all four partitions (4MB)? How would it even know which was which without checking every file on the drive to see which partition it is in? For a 4MB drive, it would not take much time, but imagine an almost full 6TB drive. You would wait for hours while 'ls' scanned every file on the drive.

'du' does this differently, but that is another very complex and technical process on how file systems maintain usage data. Suffice it to say, it does not keep track of the data you want (per-directory usage). It only keeps track of the size of entire partition and how much space is used on the entire partition so it can calculate freeSpace = totalSpace - UsedSpace. If it tried to keep track of per-directory information, it would have the same problem 'ls' has and would have to recalculate it entirely every time it changed (which again, could take hours if you only changed a single byte on a 6TB drive!)

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.