on boot, access beyond end of device
Mike -- EMAIL IGNORED
m_d_berger_1900 at yahoo.com
Tue Feb 26 18:26:11 UTC 2008
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.
More information about the users