du - df reporting ...

[twoHats]

Ouch - that hurt - I had done this entire post, got a phoine call , when i came back i had to log in and lost the whole thing!

Here goes again:

with df i get the following:

[root@GoldenFalcon etc]# df -h /home/tom/music
Filesystem Size Used Avail Use% Mounted on
/dev/hdb1 56G 1.6G 51G 4% /home/tom/music

with du i get:
[root@GoldenFalcon etc]# du -hcs /home/tom/music
36G /home/tom/music
36G total

This (36G used) is correct - the files and file system are all usable - just not reporting correctly in df - which is what most of the GUI disk stat tools use.

Any ideas?

Thanks

[serz]

Well, look what I get.

serz@insitt:~$ du -hs /usr/src
301M    /usr/src
serz@insitt:~$ df -h /usr/src
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             4.0G  1.3G  2.8G  31% /

As you can see, I get no information giving /usr/src as an argument to df.. strange, the manual says that it can do that.

I just use df to see the filesystem usage in general... for files I just use du.

[twoHats]

I just use df to see the filesystem usage in general... for files I just use du.

I guess i should have mentioned that a HD partition is mounted at music.

I work at least 50% of the time in GUI - the tools there worked before i changed my HD - they don't now.

I am trying to find out why.


Have fun -

[Dolda2000]

It's quite simple really: du and df are two quite different programs, and as such they do different things.

du collects recursive disk usage on a certain directory, and therefore gives the result you expect.

df, however, only gives information an entire filesystems. It doesn't care the slightest about certain subdirectories inside a filesystem. In more technical terms, df is just a front-end to the statfs syscall.

With no arguments, df reports the space used and available on all cur-
rently mounted filesystems (of all types). Otherwise, df reports on
the filesystem containing each argument file.

As you can see from that, if you call df with a directory as the argument, it will report information about the filesystem that the given directory resides on, not about the directory itself.

[twoHats]

Hi Dolda2000 - I understand what you are saying - and perfectly agree with you - I am simply *not* explaining the problem correctly:

1. The "dir" i am using df on is a mount point for a file system occupying hdb1

2. The mounted partition is around 55G

3. The mounted partiton contains around 36G of data.

4. I discovered this problem by looking at KDiskFree, which tells me that:
hdb1 mounted at /home/tom/music type ext2 is 55G in size and has 50.2G free

5. only then didi i jump to CL and try df and du trying to figure out why the bad reporting on KDiskFree.

you have seen my results - i hope you understand my concern! i have about 33G of data not being reported by these tools. The data is certainly there I have been listening to the music! I assume (perhaps stupidly) that KDiskFree (like most other GUI tools) used the underlying
CL tools to get thier data.

Anyway here is df with no params - the drive in question is hdb1

[root@GoldenFalcon etc]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1             12096724   5713032   5769208  50% /
none                    256948         0    256948   0% /dev/shm
/dev/hda2             11345628   1696540   9072760  16% /mnt/Berry
/dev/hda5              6893064   1230436   5312476  19% /mnt/Woody
/dev/hda6             42599672  26160720  14275000  65% /Data
/dev/hdb1             57674192   2066096  52678412   4% /home/tom/music

If i misundersatnd the tool usage - I *do* understand the reporting which is not correct. I am just trying to find out what i need to do to correct it.

Thanks again -

[serz]

With no arguments, df reports the space used and available on all cur-
rently mounted filesystems (of all types). Otherwise, df reports on
the filesystem containing each argument file.

As you can see from that, if you call df with a directory as the argument, it will report information about the filesystem that the given directory resides on, not about the directory itself.

That makes sense now. Guess I didn't read that part very well..

[Dolda2000]

I see now, twoHats. Sorry, it seems I missed that in your first post (after all, it was obvious in the df command output).

That makes it all the more stranger, of course.

The only obvious explanation I can think of is this: Did you mean that it really is ext2, and not ext3? If it is ext2, could it be you've shut down the system without umounting /home/tom/music? In that case, it may make sense. I believe that ext2 caches the usage data in the superblock, and without proper umounting, it may have become incoherent. Try fsck'ing that filesystem. I'd also recommend you convert it to ext3 instead.

[twoHats]

Hey Dolda2000 - Thanks!! The fsck was what was needed.

I didn't see it anywhere, but i seem to remember that fsck should not be done on a mounted disk. Is that right or just a bad dream i had once ?

Again thanks for the help!

[Dolda2000]

I didn't see it anywhere, but i seem to remember that fsck should not be done on a mounted disk. Is that right or just a bad dream i had once ?

That's correct; never fsck a mounted disk (as long as it isn't mounted read-only). Since the kernel filesystem drivers may keep a lot of info in internal data structures that aren't flushed to block device buffers, fsck'ing a mounted filesystem may and will most likely make the filesystem driver's data structures incoherent with the disk data, which most likely results in heavy corruption.

Of course, fsck'ing a filesystem that is mounted read-only shouldn't be a worry.

Also, as I said, you should convert it to ext3. It's really simple.

[budman7]

I wasn't aware that you could fsck a mounted filesystem.
When I was having problems with a Gentoo install, I was told to run fsck, when I did try, it wouldn't let me until I umounted it.