SCO

I don't know how to explain this any better than the thread that I supplied a link to as the first reply on this thread.

Can someone help me word this differently to dextergenious please?

I'm lost for the words (for once)!!

(The difference is due to allocated blocks (as per inode) vs actual file sizes (bytes) and the "wasted" space in between.)

How do you say that guys? I thought the link was self-explanatory but we need to make it more clear.

The point is the OP poster doesn't complain about a discrepancy between the actual file size and what du is reporting, which is what the quote is about, but about the discrepancy between df and du.

df is telling 63 GB are used, this is global file system view of free space.
du is telling 38 GB are used, this is a hierarchical, file by file computation.

The du manual page just tell the actual data file size is smaller than 38 GB but gives no clue about the 25 GB difference.

There are many reasons for having such a difference, and actually df always tells more space is used than du but the difference seems here too large so I'm trying to exclude the most usual ones with my still unanswered questions.

@dextergenious: another question: are there other file systems mounted on / and where are they ?

@jlliagre......thanks for the help here.

My understanding is (correct me if I'm wrong) that df (what we all look at as sysadmins to see how full filesystems are) regards all disk sectors (blocks) allocated as unavailable (which they are).

One file may contain, say, 4 bytes, but occupy the minimum 512 bytes (1 block), therefore the discrepancy can be huge if there are a lot of small files. The larger the files (eg. big Oracle dB) will mean occupied blocks and actual file bytes used look closer.

The df tells you filesystem occupied blocks but du is basically adding up file sizes which will be different.

Anyone disagree with that? Useful discussion this!!

I'm afraid I have to fully disagree. du isn't adding up file sizes but adding up file disk usage (as its name implies) i.e. a 4 bytes file will use at least one block.

What du isn't adding up is size it can't see, like removed but still used files, file system specific areas (e.g. journal, superblocks, ...), files hidden by an overlay mount, files unreachable by a non root user due to permissions, blocks lost due to file system corruption, and so on ...

Yea, right. Got it! That makes perfect sense.

I don't know if this is still true, but many years ago df would report less free space available for non-root users than for root users and some filesystem code would return ENOSPC errors when an application wasn't running as root even when about 10% of the space on the filesystem was still unallocated. (This was intended to allow a sys admin to have a little wiggle room to try to clean up an expanding filesystem that was almost almost full before the system became a paperweight.)

Reference post #1. Which refers only to the root filesystem.
Just in case this is the old issue with du following links.
Please post:

Code:

du -k /
du -kx /
df -k /

How many files etc. do you have in the root filesystem?

Code:

find // -xdev -print | wc -l