Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
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.
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.
Quote:
Originally Posted by The manpage for df
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.
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
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.
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..
__________________ serzsite.com.ar
"All the drugs in this world won\'t save you from yourself"
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.
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.
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.
__________________
Go RedWings
How to know if you are a geek.
when you respond to "get a life!" with "what's the URL?"
- Birger
Open Source Security Myths Dispelled Dispel the five major myths surrounding Open Source Security and gain the tools necessary to make a truly informed decision for your IT organization subscribe
InformationWeek InformationWeek is the only newsweekly you'll need to stay on top of the latest developments in information technology. subscribe
Misc Any questions or Linux discussion that does not fit in any of the other technical areas.
Submit Your Article
Latest Articles
Article Categories
Join Linux Forums Today
Linear Mode
