linux.git/drivers/md/raid5.c, branch v2.6.24

md: fix data corruption when a degraded raid5 array is reshaped

2008-01-09T00:10:35+00:00

We currently do not wait for the block from the missing device to be
computed from parity before copying data to the new stripe layout.

The change in the raid6 code is not techincally needed as we don't delay
data block recovery in the same way for raid6 yet.  But making the change
now is safer long-term.

This bug exists in 2.6.23 and 2.6.24-rc

Cc: 
Signed-off-by: Dan Williams 
Acked-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

raid5: fix unending write sequence

2007-11-15T02:45:39+00:00


handling stripe 7629696, state=0x14 cnt=1, pd_idx=2 ops=0:0:0
check 5: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ffcffcc0 written 0000000000000000
check 4: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fdd4e360 written 0000000000000000
check 3: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000
check 2: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000
check 1: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ff517e40 written 0000000000000000
check 0: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fd4cae60 written 0000000000000000
locked=4 uptodate=2 to_read=0 to_write=4 failed=0 failed_num=0
for sector 7629696, rmw=0 rcw=0


These blocks were prepared to be written out, but were never handled in
ops_run_biodrain(), so they remain locked forever.  The operations flags
are all clear which means handle_stripe() thinks nothing else needs to be
done.

This state suggests that the STRIPE_OP_PREXOR bit was sampled 'set' when it
should not have been.  This patch cleans up cases where the code looks at
sh->ops.pending when it should be looking at the consistent stack-based
snapshot of the operations flags.

Report from Joel:
	Resync done. Patch fix this bug.

Signed-off-by: Dan Williams 
Tested-by: Joel Bertrand 
Cc: 
Cc: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Add UNPLUG traces to all appropriate places

2007-11-09T12:41:32+00:00

Added blk_unplug interface, allowing all invocations of unplugs to result
in a generated blktrace UNPLUG.

Signed-off-by: Alan D. Brunelle 
Signed-off-by: Jens Axboe

md: fix misapplied patch in raid5.c

2007-11-05T23:12:32+00:00

commit 4ae3f847e49e3787eca91bced31f8fd328d50496 ("md: raid5: fix
clearing of biofill operations") did not get applied correctly,
presumably due to substantial similarities between handle_stripe5 and
handle_stripe6.

This patch moves the chunk of new code from handle_stripe6 (where it isn't
needed (yet)) to handle_stripe5.

Signed-off-by: Neil Brown 
Cc: "Dan Williams" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

md: raid5: fix clearing of biofill operations

2007-10-23T15:32:06+00:00

ops_complete_biofill() runs outside of spin_lock(&sh->lock) and clears the
'pending' and 'ack' bits.  Since the test_and_ack_op() macro only checks
against 'complete' it can get an inconsistent snapshot of pending work.

Move the clearing of these bits to handle_stripe5(), under the lock.

Signed-off-by: Dan Williams 
Tested-by: Joel Bertrand 
Signed-off-by: Neil Brown 
Cc: Stable 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

block: convert blkdev_issue_flush() to use empty barriers

2007-10-16T09:05:02+00:00

Then we can get rid of ->issue_flush_fn() and all the driver private
implementations of that.

Signed-off-by: Jens Axboe

Drop 'size' argument from bio_endio and bi_end_io

2007-10-10T07:25:57+00:00

As bi_end_io is only called once when the reqeust is complete,
the 'size' argument is now redundant.  Remove it.

Now there is no need for bio_endio to subtract the size completed
from bi_size.  So don't do that either.

While we are at it, change bi_end_io to return void.

Signed-off-by: Neil Brown 
Signed-off-by: Jens Axboe

raid5: fix 2 bugs in ops_complete_biofill

2007-09-24T20:23:35+00:00

1/ ops_complete_biofill tried to avoid calling handle_stripe since all the
state necessary to return read completions is available.  However the
process of determining whether more read requests are pending requires
locking the stripe (to block add_stripe_bio from updating dev->toead).
ops_complete_biofill can run in tasklet context, so rather than upgrading
all the stripe locks from spin_lock to spin_lock_bh this patch just
unconditionally reschedules handle_stripe after completing the read
request.

2/ ops_complete_biofill needlessly qualified processing R5_Wantfill with
dev->toread.  The result being that the 'biofill' pending bit is cleared
before handling the pending read-completions on dev->read.  R5_Wantfill can
be unconditionally handled because the 'biofill' pending bit prevents new
R5_Wantfill requests from being seen by ops_run_biofill and
ops_complete_biofill.

Found-by: Yuri Tikhonov 
[neilb@suse.de: simpler fix for bug 1 than moving code]
Signed-off-by: NeilBrown 
Signed-off-by: Dan Williams

md: fix some bugs with growing raid5/raid6 arrays.

2007-09-12T00:21:19+00:00

The recent changed to raid5 to allow offload of parity calculation etc
introduced some bugs in the code for growing (i.e.  adding a disk to) raid5
and raid6.  This fixes them

Acked-by: Dan Williams 
Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[BLOCK] Get rid of request_queue_t typedef

2007-07-24T07:28:11+00:00

Some of the code has been gradually transitioned to using the proper
struct request_queue, but there's lots left. So do a full sweet of
the kernel and get rid of this typedef and replace its uses with
the proper type.

Signed-off-by: Jens Axboe