On Tue, 26 Feb 2008 09:54:11 -0700, Phil Meyer wrote:
Todd Denniston wrote:
[...]
Assumption: A) 4K inodes in the file system, B) /dev/mapper/VolGroup00-LogVol00 is on dm-0 only. C) /proc/partitions is the correct thing to be comparing against.
try confirming: tune2fs -l /dev/mapper/VolGroup00-LogVol00 |grep "Block count:" is equal to 75956224/4 = 18989056
to be sure of the method look at tune2fs -l /dev/sda1|grep "Block count:" compared with: 104391/4 = 26097
IIRC "Block count:" from tune2fs is how big the file system things the hard drive/volume group is. IIRC the df data is skewed by the "Reserved block count" and possibly the Journal size.
Yes, but the df output should not be LARGER than the /proc/partitions number. It seems reasonable that it could/should be smaller.
So my wording of identifying a mismatch was poor. Perhaps it should be said that the df number if larger than the /proc/partitions number indicates this type of problem.
Sorry for the confusion. It was clear in my head when I wrote it, can't you read my mind? :)
The values in /proc/partitions are larger than df values on all three of my Linux systems, 1 FC7 and 2 FC8, one of which I just installed to fix the problem box. Here are two additional points:
1. When installing on the problem box, the installation software informed me that it could not read a track; I don't remember what it was, but it sounded related. For unrelated reasons, I redid that installation. On the second try, there was no such report. I note also that before these installs, I ran memtest86 and fsck, and found no problem.
2. Remember that the problem box has 125M ram, 20G disk, 400 MHZ. Furthermore, in some recent operations, I filled the disk to about 85%. At least in my case, no other hard drive is filled that full. I wonder if this is part of the problem.
Mike.