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
