[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Bad directories appearing in ext3 after upgrade 2.4.16 -> 2.4.18+cvs



On Tuesday May 21, sct redhat com wrote:
> >  I get quite a few messages in the logs which say:
> >   
> > May 21 14:20:06 glass kernel: raid5: multiple 1 requests for sector 7540536
> 
> Can you go into debugfs and find out what inode that sector belongs
> to?  You'll need to convert it into a block number first, then use
> "icheck".

Unfortunately the "convert to block number" bit is tricky.  The sector
number is a sector on a component drive, so the relationship to
filesystem blocks is subtle, and there could be 3 different blocks
that it could be (one for each data drive).

I will augment the message a bit in the next kernel that I boot to
print a more usefu sector number.

> 
> >  For a variety of sector numbers.
>  
> >  This means that raid5 has received two separate write requests, with
> >  two separate buffer heads, for the same sector.  This seems like a
> >  filesystem error to me.
> 
> Probably, yes.  Is this a SMP box?  I recently fixed a long-standing
> bug which could cause that on SMP; it would be worth seeing if the
> ext3-0.9.18 I posted fixes the problems.  Are you running dump(8)?  If
> so, it could actually be a read request from dump colliding with a
> write request from the fs; add_write_bh() doesn't seem to distinguish
> between reads and writes when warning about IO collisions.

SMP-yes.

ext3-0.9.18 ... I really want to go back to something that I vaguely
trust, namely the 2.4.17-pre2 kernel that I was running plus the fix
for the assertion that failed.  Now is not a time for experiments.
But I will look at the code in 0.9.18 and see if there seems to be
something that I am happy to use.

dump(8) - no, but I scan the inode tables check disk space usage
but not often enough to get the rate of messages that  I am seeing.

And add_stripe_bh does distinguish between reads and writes.  There
are two lists of buffers, sh->bh_read[idx] and sh->bh_write[idx].  One
is the list of buffers wanting to read this block, the other is the
list of buffers wanting to write this block.  We only get a warning
when adding to a list that already has members.

> 
> Otherwise, I'd really like to track this down by turning the raid
> warning into a BUG() or BH_ASSERT(), and enable buffer tracing.  (In
> fact I can probably do that non-destructively, by calling the buffer
> trace printing manually from add_stripe_bh().)

Reasonable, but not on my production server of course.  I might try it
on my test machine and see if I can create a load that generates these
messages.

Thanks,

NeilBrown





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]