on boot, access beyond end of device

[Mike -- EMAIL IGNORED]

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.