[plug] Ext3: attempt to access beyond end of device

[Alex Nordstrom]

Ran into some nastiness with the filesystem today. After a brief panic 
attack, it seems the damage was (knock on wood) quite limited, but it's 
always an uneasy feeling when things like this happen, so I'd like to 
hear your views as to what may be the cause.

I'm using Debian Sid with 2.6.8-2-686 and the following fstab entries:

proc            /proc           proc    defaults                   0 0
/dev/hda6       /               ext3    defaults,errors=remount-ro 0 1
/dev/hda3       /data           ext3    nodev                      0 2
/dev/hdc2       /home           ext3    nodev,nosuid               0 2
/dev/hda7       /tmp            ext3    noatime,nodev,nosuid       0 2
/dev/hda5       /usr            ext2    nodev,ro                   0 2
/dev/hda8       /var            ext3    nodev,nosuid,noexec        0 2
/dev/hda1       none            swap    sw,pri=-1                  0 0
/dev/hdc1       none            swap    sw,pri=-1                  0 0
/dev/sda1       /media/nikon    vfat    defaults,user,noauto       0 0
/dev/sdb1       /media/fuji     vfat    defaults,user,noauto       0 0

hda is a WDC WD136BA, 26712000 sectors (13676 MB) w/2048KiB Cache, 
CHS=26500/16/63, UDMA(33)

hdc is an IBM-DJNA-372200, 44150400 sectors (22605 MB) w/1966KiB Cache, 
CHS=43800/16/63, UDMA(33)

I realise my disk is getting a bit full:

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda6             228M   77M  140M  36% /
tmpfs                 189M  4.0K  189M   1% /dev/shm
/dev/hda3             6.5G  5.9G  335M  95% /data
/dev/hdc2              21G   17G  3.3G  84% /home
/dev/hda7             912M  8.2M  855M   1% /tmp
/dev/hda5             2.9G  1.7G  1.1G  62% /usr
/dev/hda8             1.8G  556M  1.2G  33% /var

...but >3 GiB still seems like it should be something I could live with 
without the following sort of entries popping up in the logs:

23:55:52 attempt to access beyond end of device
23:55:52 hdc2: rw=0, want=1073741832, limit=43775424
23:55:52 EXT3-fs error (device hdc2): ext3_free_blocks: Freeing blocks 
not in datazone - block = 134217728, count = 1
23:55:52 Aborting journal on device hdc2.
23:55:52 ext3_abort called.
23:55:52 EXT3-fs abort (device hdc2): ext3_journal_start: Detected 
aborted journal
23:55:52 Remounting filesystem read-only
23:55:52 EXT3-fs error (device hdc2) in start_transaction: Journal has 
aborted
23:55:52 last message repeated 2 times
23:55:52 ext3_reserve_inode_write: aborting transaction: Journal has 
aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device 
hdc2) in ext3_reserve_inode_write: Journal has aborted

...and so on. After a reboot, an fsck was forced, and unsurprisingly, an 
inode pointing to somewhere that didn't exist was found, which I 
cleared. After another reboot, things seem relatively normal, apart 
from a bunch of.

00:14:34 Device not ready.  Make sure there is a disc in the drive.
00:14:34 Device sda not ready.

For sda through sdd, which weren't there before. sda and sdb as 
specified in the fstab are manually mounted USB MSDs. I have no idea 
what would try to reach them, much less sdc and sdd.

hdc is sitting at 49 degrees, and I guess that might be a bit on the 
toasty side. I also know very little about its history, having bought 
it as part of a second-hand (s)crap system, but it's held up nicely for 
about a year now, having been in constant use for the past two or three 
months. Still, it doesn't seem hardware-ish when the kernel tries to 
grab a sector on the disk one milliard sectors off the end of the disk.

So the questions present themselves: what may have caused this, and how 
can I avoid it happening again? What's more likely: impending hardware 
failure of doom, or software glitch (of equal doom)?

-- 
Alex Nordstrom
http://lx.n3.net/
Please do not CC me in followups; I am subscribed to plug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20050512/d975fcd6/attachment.pgp>