Search Results

If you don't add the "-o full", SCO vxfs fsck doesn't check the file system. It just flushes the journal.
Neither do I as you posted it, please use code tags.

Did you run a full fsck ? (by default, fsck only checks the log with vxfs)
fsck -n -o fullAre you using a database ? AFAIK, vxfs supports specific extents that provide raw device like access that...

What about:
- telling what file system type you use ?
- running du on this file system while booted from a live media (emergency_disk) ?
- running fsck ?

I'm not familiar enough with SCO but I guess it support more than one file system type so are you using the same one, and which one is it ?

@dextergenious: you are right with the -v option. As it...

df -k / will only show statistics belonging to the / file system. Mounted file systems information is never merged by df.
The -v option is useless with df.

But note that du, at least on SCO as you demonstrated, has the odd behavior to account space used on non disk based file system entities.
Edit: Solaris is actually doing the same, one more reason to...

Unlikely.
There is no rule.

You should use du -xk to limit du to the / file system.

You must be root otherwise du would miss files you have no privilege to read (Note: SCO du manual page...

That would be another serious bug if true. /proc doesn't use disk space so du should report 0 blocks for any file in it.

---------- Post updated at 16:42 ---------- Previous update was at 16:37...

/stand is not a partition and not even a file system, the partition containing the file system is named /dev/boot. /stand is simply a directory initially created in the /dev/root file system mounted...

Not that it is necessarily the root cause of your problem but I'm afraid you are still missing what I mean. You need to unmount /stand to know if this directory is empty or not in the first place.

What matters here is not /stand file system size but the size of what might be present under the /stand directory when no file system is mounted there.

If one of your non root file systems (eg: /var, /opt, /export, ...) is mounted on a previously non empty directory, this directory size is unaccounted by du.

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...

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.
...

@dextergenious: again, is this discrepancy still there after a reboot ?

Is your file system clean ? (fsck)

You should post both du -k and df -k precise output. dfspace is apparently a just df wrapper.
Is the discrepancy still there after a reboot ?