I am trying to figure out the dir size of one of my dirs, and as far as I can tell the du command is the most appropriate for the job. However it doesn't appear to scan recursively correctly so I'm running the command independently on my 3 most important subfolders. One of them produces this output:

That seriously almost looks like the folder is 16777215 Terabytes in size!!! That can't be right? What's going on here?

Btw, if I run the "du" command on the parent directory, which is really what I'd like to do, then I only get this output:
Note: This is NOT on my mac. This is a linux system.

Do you really have a directory at the root level named "volume1"?

Try also "du -h <path>"---see if there is a particular subdirectory that's causing the issue

Yup, I do have a directory at root named "volume1" and the video dir is really inside of it.

Also, inside of the video dir there are an insane amount of sub-dirs when you get below the first two levels. The video dir has only 5 sub-dirs and all except one of them are larger than the 86G that the du command prints when I point it directly at the video dir. What am I looking for to spot an issue exactly?

Your results are strange. Doing the the same thing on my system, it gives a larger size for the parent directory than for the subdirectory (which is what is expected if the parent directory contains additional items to the subdirectory):

Hi,

Only thing that comes to mind: Is MOVIES a none linux file system (NTFS maybe)?

I've read about issues with du and NTFS file systems, something to do with the way NTFS reports the asked information to du. Haven't seen any solutions though.

If MOVIES is a mounted FS, you can also use the df command df -h | grep MOVIES

Hope this helps.

Everything is ext3 formatted. As per your suggestion I tried using "df" instead of "du" but it produced the exact same result as "du". No change at all.

Hi,

Can I assume from your answer (#6) that MOVIES is indeed a mounted partition?

If so: Unmount it and check it using fsck, it could be that some repair work is needed.

Something like: fsck -y /dev/sxy0 (replace sxy0 with correct device). -y tells fsck to always try to repair found errors (if any).

Hope this helps.

No, sorry, it's not a mounted partition.

Hi,

The same as in the correct or the incorrect output?

If the incorrect output is shown, you should make sure that that specific partition is clean. Run the fsck command on that partition (do unmount it first).

Hope this helps.

I don't quite follow you here. Basically this system has 3 HDD running in RAID 5. There is a couple of small system partitions and then there is a large file/storage partition where I keep all my files.

As per your first suggestion I tried copying the command you had written with "grep" and everything. That produced no output what so ever. So I simply wrote "df" into the terminal and it spat out a list of all my folders and their sizes, same as the du command does. And the filesizes of the du command and df command are the same.

Hi,

Ok, with the extra info given (this system has 3 HDD running in RAID 5. Should have been in your first post ) my solution will not work.

Maybe this new info will trigger some other responses.

I just thought of something. What about symbolic links? Previously, the files that now exist in the video folder were only reference there by symbolic links. That is, there were no actual files in that dir previously, but then I moved all the files into the "video" directory without ever removing the symbolic links. Of course, the folder the symbolic links pointed to is now deleted so even if they were there they wouldn't point anywhere right? And besides, the "du" command is by defualt not supposed to follow symbolic links. Right?