Paul E Condon wrote: > Roger Leigh wrote: > > Dom wrote: > > > I'd try bringing the system up in recovery mode, unmount all ext3 > > > file systems (except /, obviously) and run the du command again. You > > > might find data that was concealed under the mount points. > > > > It's even possible that it's under /tmp. > > Some issues with some suggestions: > > 1) If the data is actually there, it is obviously on my rootfs (/) which > I obviously can't examine in recovery mode. Or can I examine it by some > trickery that someone will tell about? There is no trickery. The root filesystem is plainly available when booted into recovery mode. Simply run the du commands there. Why do you think it needs trickery? > 2) I used mv to move the data, from past experience I judged the execution > time of mv to be consistent with the same about of data the showed up on > /mpb2 according to du. You used 'mv' to move what data? I looked through your previous postings but don't see any background on this. You are moving data? What data? > 4) I started making proparations to wipe and reinstall on the > problem computer. To do that I was working on an entirely different > computer (the one on which I read my mail). I wanted to clean up > some partitioning there. This other computer is running Squeeze. I > installed kpartx, tried to use it, and got a real surprise: > > root@big:~# kpartx -l /dev/sda Stop! Proceed no further. What are you trying to do here? Why are you using kpartx here? What does the kernel say about your partitions: cat /proc/partitions > /proc/misc: No entry for device-mapper found > Is device-mapper driver missing from kernel? > Failure to communicate with kernel device-mapper driver. > sda1 : 0 39061504 /dev/sda 2048 > sda2 : 0 39061504 /dev/sda 39063552 > sda4 : 0 894738434 /dev/sda 82032638 > sda5 : 0 894738432 /dev/dm-2 2 > root@big:~# All pretty much expected. What did you expect? The above is *exactly* what I would expect to see. But why are you trying to use kpartx on /dev/sda here? Stop! You are off lost in the woods. Stay on the trail. (I could explain the various uses of kpartx but I don't think it would help so will refrain.) > the internet. Perhaps I should take a deep breath and reinstall all three > of my computers. This course of action will take a long time, and it will > keep me from asking (or answering) questions on this list for a long time. Oh, don't tease us so! :-) > Is device-mapper driver a standard part of all Debian kernels? It is a kernel module. Modules are only loaded if you need them. You don't need this one and so it hasn't been loaded. > Is df really more to be trusted than du when used on a disk that > could have become corrupted? If you suspect disk corruption here (I don't, I think it is fine) then run fsck on the filesystem. > As I understand du, it works by walking the directory tree and > tallying the space used by all the objects that it finds. The -s > option only affects how verbose it is in reporting what it has > found. In other words, if du doesn't find something on a disk, why > should one search manually and expect to find something that it > missed. Maybe I should look for something that absolutely should not > be there and is a clue about what made the disk 'go south'? There are many reasons for disk space to be visible in one context and invisible in another context. That isn't unusual at all. Any disk space under a mounted filesystem is invisible. But it is still used disk space. This can happen when /tmp is used for lots of files and disk space but then another /tmp is mounted on top of it. This additional one covers up the one below it. Any files that have been written to but have been unlinked from the directory will consume space but be invisible. This often happens with log files. A program writes a log file. It writes a lot of data to the log file. A person sees that and thinks, I will remove the file. That is the worst possible thing to do. Having removed the file from the directory the program is still writing to it. Therefore the disk space used by it is still used by it. The space will only be freed up when the program writing to it is killed. This is all due to the filesystem using reference counting. The file is only freed when all of the file handles to it are reduced to zero. As long as at least one file handle points to the file then it cannot be freed. By reading your messages I think either of these two reasons are very likely. Bob
Attachment:
signature.asc
Description: Digital signature