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

md: close a livelock window in handle_parity_checks5

2008-04-11T15:06:44+00:00

If a failure is detected after a parity check operation has been initiated,
but before it completes handle_parity_checks5 will never quiesce operations on
the stripe.

Explicitly handle this case by "canceling" the parity check, i.e.  clear the
STRIPE_OP_CHECK flags and queue the stripe on the handle list again to refresh
any non-uptodate blocks.

Kernel versions >= 2.6.23 are susceptible.

Cc: 
Cc: NeilBrown 
Signed-off-by: Dan Williams 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/md/raid5.c: fix printk warnings

2008-03-20T01:53:37+00:00

gcc-3.4.5 on sparc64:

drivers/md/raid5.c: In function `raid5_end_read_request':
drivers/md/raid5.c:1147: warning: long long unsigned int format, long unsigned int arg (arg 4)
drivers/md/raid5.c:1164: warning: long long unsigned int format, long unsigned int arg (arg 3)
drivers/md/raid5.c:1170: warning: long long unsigned int format, long unsigned int arg (arg 3)

sector_t is u64, and we don't know what type the architecture uses to
implement u64 (on some it is unsigned long).

Cc: Neil Brown 
Cc: "J. Bruce Fields" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

md: fix an occasional deadlock in raid5

2008-02-06T18:41:19+00:00

raid5's 'make_request' function calls generic_make_request on underlying
devices and if we run out of stripe heads, it could end up waiting for one of
those requests to complete.  This is bad as recursive calls to
generic_make_request go on a queue and are not even attempted until
make_request completes.

So: don't make any generic_make_request calls in raid5 make_request until all
waiting has been done.  We do this by simply setting STRIPE_HANDLE instead of
calling handle_stripe().

If we need more stripe_heads, raid5d will get called to process the pending
stripe_heads which will call generic_make_request from a

This change by itself causes a performance hit.  So add a change so that
raid5_activate_delayed is only called at unplug time, never in raid5.  This
seems to bring back the performance numbers.  Calling it in raid5d was
sometimes too soon...

Neil said:

  How about we queue it for 2.6.25-rc1 and then about when -rc2 comes out,
  we queue it for 2.6.24.y?

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

md: change ITERATE_RDEV to rdev_for_each

2008-02-06T18:41:19+00:00

As this is more in line with common practice in the kernel.  Also swap the
args around to be more like list_for_each.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

md: allow a maximum extent to be set for resyncing

2008-02-06T18:41:18+00:00

This allows userspace to control resync/reshape progress and synchronise it
with other activities, such as shared access in a SAN, or backing up critical
sections during a tricky reshape.

Writing a number of sectors (which must be a multiple of the chunk size if
such is meaningful) causes a resync to pause when it gets to that point.

Signed-off-by: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

md: Update md bitmap during resync.

2008-02-06T18:41:18+00:00

Currently an md array with a write-intent bitmap does not updated that bitmap
to reflect successful partial resync.  Rather the entire bitmap is updated
when the resync completes.

This is because there is no guarentee that resync requests will complete in
order, and tracking each request individually is unnecessarily burdensome.

However there is value in regularly updating the bitmap, so add code to
periodically pause while all pending sync requests complete, then update the
bitmap.  Doing this only every few seconds (the same as the bitmap update
time) does not notciably affect resync performance.

[snitzer@gmail.com: export bitmap_cond_end_sync]
Signed-off-by: Neil Brown 
Cc: "Mike Snitzer" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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