I (along with many others) have been experiencing some lockups, file
corruption and "attempt to access beyond end of device" messages. The only
common thread I've seen is that we all have EXT2 filesystems.
What happens when you run e2fsck on the filesystem? If it's clean, it's
very likely that the problem is that blocks are getting corrupted as
they are getting read into your system. I would take a very careful
look at the length of your IDE or SCSI cables, run disk diagnostics, etc.
In reviewing fs/ext2/inode.c there seem to be a lot of places where error
conditions are not being checked. Particularly where "bh =" assignments are
occurring.
Can you send me explicit cases where you think they're not getting
checked? I checked all of the "bh = " assignments in fs/ext2/inode.c,
and they are correct. You may have missed the fact that in some cases,
where inode_getblk() or block_getblk() are called, if they return NULL,
then subsequent calls to block_getblk() with a NULL bh cause that
function to return immediately, with the error code still set in the
*err parameter. Hence, even though there isn't an explicit error
condition check happening, the right thing does happen on an error.
It's just a little bit more subtle than might be obvious on first
inspection.
Some of my messages show ASCII data in the "want=" portion of
the "attempt to access beyond" message.
Well, that means the ext2 filesystem found ASCII data in either the
inode table or an indirect metatdata block. There are three explanations
for this; one is that the wrong block was read by the disk drive when
reading the metadata block; one is that some data block was written to
the wrong place and hence stomped on a metadata block; and the third is
that some kernel bug has caused a corruption in the buffer cache, which
then is getting detected right away or is written back to disk and then
detected later.
Most of the time, the reason for these errors is a hardware problem of
one kind or another. It's possible it's being caused by something else,
including a kernel bug, but if that were the case we'd typically see a
lot more complaints about it, especially if you can easily reproduce
this on your system. I'd strongly advise you to take a close look at
your disk drives, cables, and controllers on your system, and consider
what might have changed since when you first started seeing these
errors.
Also, in fs/buffer.c in the call "init_buffer" the bh->b_size and
bh->b_rsector are not initialized. So, if one of the "bh =" calls has an
error in inode.c then bh->b_rsector is quite likely to contain random data
and will (possibly) die on the next ll_rw_block call. In my case I was
doing gigabytes of ASCII i/o so I saw my ASCII data in the message (in hex
of course). In other cases the random value of bh->b_sector would allow the
ll_rw_block call to succeed possibly corrupting files (I've not seen any
corruption yet myself).
Huh? If one of the "bh =" calls has an error, then bh is NULL. I don't
think you understand the calling convention used on these calls.....
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/