Re: (2.5.23) buffer layer error at buffer.c:2326

From: Andrew Morton (akpm@zip.com.au)
Date: Wed Jun 19 2002 - 15:02:32 EST


Zwane Mwaikambo wrote:
>
> The ide drive holding the mounted filesystem dropped out of DMA and then
> spewed the following a number of times. Anyone interested?
>
> buffer layer error at buffer.c:2326

y'know, just this morning I was thinking it may be time to pull the
debug code out of buffer.c. Silly me.

So we had a non-uptodate buffer against an uptodate page. Were
there any other messages in the logs? I'd have expected a
"buffer IO error" to come out first?

Looking at the code, it seems likely that you hit an I/O error
on a write. That will leave the page uptodate, but with PageError
set. And the buffer is marked not uptodate, which is silly, because the
buffer _is_ uptodate.

What this says is: I still need to get down and set up a fault simulator
and make sure that we're doing all the right things when I/O errors occur.

Does anyone have any opinions on what the kernel's behaviour should
be in the presence of a write I/O error? Our options appear to be:

1: Just drop the data. That's what we do now.

2: Mark it dirty again, so it gets written indefinitely

3: Mark the page dirty again, but also set PageError. So we
   attempt to write the same blocks a second time only. Then
   drop the data.

4: (Just thought of this): mark the page PageError and PageDirty,
   and unmap it from disk. So when it gets written again, the
   filesystem's get_block function will be called. It can look at
   PageError(bh_result->b_page) and say "hey, I need to find a
   different set of blocks for this page". The bad blocks will
   just be leaked.

   To back that up: if we get an IO error and the page is _already_
   PageError, give up. Mark it clean and lose the data. This gives the
   fs the option of clearing PageError inside get_block(), so it will end
   up trying every block on the disk.

   Pretty sneaky, I think. But it only works for file data. If the
   blocks are for metadata, we're screwed..

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:20 EST