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.
