My minimal FC7 box has 125M ram, 20G hard drive, 400 MHZ. I have been successfully using it for a web server. Recently it has been generating a huge number of:
attempt to access beyond end of device
Below are some messages produced on a reboot showing the problems. I note that df shows no sda2. After suggestions on a previous thread, I ran memory and disk tests, and found no problems.
Thanks for your assistance.
Mike.
--
Feb 25 16:39:54 mbrc20 kernel: sda: sda1 sda2 Feb 25 16:39:54 mbrc20 kernel: sda: p2 exceeds device capacity Feb 25 16:39:54 mbrc20 kernel: sd 0:0:0:0: [sda] Attached SCSI disk Feb 25 16:39:54 mbrc20 kernel: scsi 0:0:1:0: Direct-Access IOMEGA ZIP 100 14.A PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: sd 0:0:1:0: [sdb] Attached SCSI removable disk Feb 25 16:39:54 mbrc20 kernel: scsi 1:0:0:0: CD-ROM PLEXTOR CD-R PX-W2410A 1.02 PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: scsi 1:0:1:0: CD-ROM NEC CD-ROM DRIVE:28D 3.04 PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=40017743, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=40017743, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=39923925, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: Buffer I/O error on device dm-1, logical block 131056 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=39923925, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: Buffer I/O error on device dm-1, logical block 131056
Mike -- EMAIL IGNORED wrote:
My minimal FC7 box has 125M ram, 20G hard drive, 400 MHZ. I have been successfully using it for a web server. Recently it has been generating a huge number of:
attempt to access beyond end of device
Below are some messages produced on a reboot showing the problems. I note that df shows no sda2. After suggestions on a previous thread, I ran memory and disk tests, and found no problems.
Thanks for your assistance.
Mike.
--
Feb 25 16:39:54 mbrc20 kernel: sda: sda1 sda2 Feb 25 16:39:54 mbrc20 kernel: sda: p2 exceeds device capacity Feb 25 16:39:54 mbrc20 kernel: sd 0:0:0:0: [sda] Attached SCSI disk Feb 25 16:39:54 mbrc20 kernel: scsi 0:0:1:0: Direct-Access IOMEGA ZIP 100 14.A PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: sd 0:0:1:0: [sdb] Attached SCSI removable disk Feb 25 16:39:54 mbrc20 kernel: scsi 1:0:0:0: CD-ROM PLEXTOR CD-R PX-W2410A 1.02 PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: scsi 1:0:1:0: CD-ROM NEC CD-ROM DRIVE:28D 3.04 PQ: 0 ANSI: 5 Feb 25 16:39:54 mbrc20 kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=40017743, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=40017743, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=39923925, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: Buffer I/O error on device dm-1, logical block 131056 Feb 25 16:39:54 mbrc20 kernel: attempt to access beyond end of device Feb 25 16:39:54 mbrc20 kernel: sda: rw=0, want=39923925, limit=39062500 Feb 25 16:39:54 mbrc20 kernel: Buffer I/O error on device dm-1, logical block 131056
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
Allot of the brand new Nokia N810s are shipping with this problem, due to the manufacturer copying the disk image of a slightly different model disk to the current one.
If the partition sizes between those two commands do not match, then you are at a trouble spot. You should not add any more data to that drive. The symptoms described match exactly the symptoms of filling up a drive with invalid partition sizes. It can work for years, as long as you don't go above a certain percentage used, depending upon the size of the error.
I would recommend, if they do not match, that you backup, wipe, repartition, mkfs, boot from rescue and check again, and if ok restore.
On Mon, 25 Feb 2008 15:07:20 -0700, Phil Meyer wrote:
[...]
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
Allot of the brand new Nokia N810s are shipping with this problem, due to the manufacturer copying the disk image of a slightly different model disk to the current one.
If the partition sizes between those two commands do not match, then you are at a trouble spot. You should not add any more data to that drive. The symptoms described match exactly the symptoms of filling up a drive with invalid partition sizes. It can work for years, as long as you don't go above a certain percentage used, depending upon the size of the error.
I would recommend, if they do not match, that you backup, wipe, repartition, mkfs, boot from rescue and check again, and if ok restore.
Indeed they do not match. I'll take the opportunity to upgrade to FC8.
Thanks, Mike.
On Mon, 25 Feb 2008 22:45:23 +0000, Mike -- EMAIL IGNORED wrote:
On Mon, 25 Feb 2008 15:07:20 -0700, Phil Meyer wrote:
[...]
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
Allot of the brand new Nokia N810s are shipping with this problem, due to the manufacturer copying the disk image of a slightly different model disk to the current one.
If the partition sizes between those two commands do not match, then you are at a trouble spot. You should not add any more data to that drive. The symptoms described match exactly the symptoms of filling up a drive with invalid partition sizes. It can work for years, as long as you don't go above a certain percentage used, depending upon the size of the error.
I would recommend, if they do not match, that you backup, wipe, repartition, mkfs, boot from rescue and check again, and if ok restore.
Indeed they do not match. I'll take the opportunity to upgrade to FC8.
Thanks, Mike.
I just looked at one of my other boxes, an FC7, which appears to have a similar mismatch, but I have not had a problem with it (yet).
[root@mbrc32 ~]# cat /proc/partitions major minor #blocks name
8 0 78150744 sda 8 1 104391 sda1 8 2 78043770 sda2 253 0 75956224 dm-0 253 1 2031616 dm-1
[root@mbrc32 ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 73575592 14177456 55600328 21% / /dev/sda1 101086 18584 77283 20% /boot tmpfs 517536 4 517532 1% /dev/shm
Similar small discrepancies appear on the newly installed FC8. Are we sure that this is a problem?
Mike.
On Mon, 2008-02-25 at 15:07 -0700, Phil Meyer wrote:
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
On two of my systems, including a long-running and reliable FC4 system, those two command outputs disagree with each other. I haven't checked the others, but I expect a similar story.
Mike -- EMAIL IGNORED wrote, On 02/25/2008 06:56 PM:
On Mon, 25 Feb 2008 22:45:23 +0000, Mike -- EMAIL IGNORED wrote:
On Mon, 25 Feb 2008 15:07:20 -0700, Phil Meyer wrote:
[...]
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
Allot of the brand new Nokia N810s are shipping with this problem, due to the manufacturer copying the disk image of a slightly different model disk to the current one.
If the partition sizes between those two commands do not match, then you are at a trouble spot. You should not add any more data to that drive. The symptoms described match exactly the symptoms of filling up a drive with invalid partition sizes. It can work for years, as long as you don't go above a certain percentage used, depending upon the size of the error.
I would recommend, if they do not match, that you backup, wipe, repartition, mkfs, boot from rescue and check again, and if ok restore.
Indeed they do not match. I'll take the opportunity to upgrade to FC8.
Thanks, Mike.
I just looked at one of my other boxes, an FC7, which appears to have a similar mismatch, but I have not had a problem with it (yet).
[root@mbrc32 ~]# cat /proc/partitions major minor #blocks name
8 0 78150744 sda 8 1 104391 sda1 8 2 78043770 sda2 253 0 75956224 dm-0 253 1 2031616 dm-1
[root@mbrc32 ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 73575592 14177456 55600328 21% / /dev/sda1 101086 18584 77283 20% /boot tmpfs 517536 4 517532 1% /dev/shm
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.
Todd Denniston wrote:
Mike -- EMAIL IGNORED wrote, On 02/25/2008 06:56 PM:
On Mon, 25 Feb 2008 22:45:23 +0000, Mike -- EMAIL IGNORED wrote:
On Mon, 25 Feb 2008 15:07:20 -0700, Phil Meyer wrote:
[...]
compare the numbers between:
# cat /proc/partitions
and the first column of:
# df
What might have happened long long ago and far far away, is that fdisk incorrectly calculated the partition size. It has been known to do that.
Allot of the brand new Nokia N810s are shipping with this problem, due to the manufacturer copying the disk image of a slightly different model disk to the current one.
If the partition sizes between those two commands do not match, then you are at a trouble spot. You should not add any more data to that drive. The symptoms described match exactly the symptoms of filling up a drive with invalid partition sizes. It can work for years, as long as you don't go above a certain percentage used, depending upon the size of the error.
I would recommend, if they do not match, that you backup, wipe, repartition, mkfs, boot from rescue and check again, and if ok restore.
Indeed they do not match. I'll take the opportunity to upgrade to FC8.
Thanks, Mike.
I just looked at one of my other boxes, an FC7, which appears to have a similar mismatch, but I have not had a problem with it (yet).
[root@mbrc32 ~]# cat /proc/partitions major minor #blocks name
8 0 78150744 sda 8 1 104391 sda1 8 2 78043770 sda2 253 0 75956224 dm-0 253 1 2031616 dm-1
[root@mbrc32 ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 73575592 14177456 55600328 21% / /dev/sda1 101086 18584 77283 20% /boot tmpfs 517536 4 517532 1% /dev/shm
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? :)
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.