linux/drivers/md, branch v2.6.16.50

md: fix /proc/mdstat refcounting

2007-03-26T21:43:10Z

I have seen mdadm oops after successfully unloading md module. This patch privents from unloading md module while mdadm is polling /proc/mdstat. Signed-off-by: Akinbou Mita Signed-off-by: Adrian Bunk

fix read past end of array in md/linear.c

2007-03-26T21:42:40Z

When iterating through an array, one must be careful to test one's index variable rather than another similarly-named variable. The loop will read off the end of conf->disks[] in the following (pathological) case: % dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1 % for i in 2 3 4; do dd if=/dev/zero of=d$i bs=1k count=$(($i+150)); done % ./vmlinux ubd0=root ubd1=d1 ubd2=d2 ubd3=d3 ubd4=d4 # mdadm -C /dev/md0 --level=linear --raid-devices=4 /dev/ubd[1234] adding some printks, I saw this: [42949374.960000] hash_spacing = 821120 [42949374.960000] cnt = 4 [42949374.960000] min_spacing = 801 [42949374.960000] j=0 size=820928 sz=820928 [42949374.960000] i=0 sz=820928 hash_spacing=820928 [42949374.960000] j=1 size=64 sz=64 [42949374.960000] j=2 size=64 sz=128 [42949374.960000] j=3 size=64 sz=192 [42949374.960000] j=4 size=1515870810 sz=1515871002 Signed-off-by: Adrian Bunk

md: pass down BIO_RW_SYNC in raid{1,10}

2007-03-26T21:41:58Z

md raidX make_request functions strip off the BIO_RW_SYNC flag, thus introducing additional latency. Fixing this in raid1 and raid10 seems to be straightforward enough. For our particular usage case in DRBD, passing this flag improved some initialization time from ~5 minutes to ~5 seconds. Signed-off-by: Lars Ellenberg Acked-by: NeilBrown Signed-off-by: Adrian Bunk

md: Fix bug where spares don't always get rebuilt properly when they become live

2007-03-26T21:41:22Z

If save_raid_disk is >= 0, then the device could be a device that is already in sync that is being re-added. So we need to default this value to -1. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk

MD: Fix problem where hot-added drives are not resynced.

2007-03-26T21:40:42Z

If a drive is added with HOT_ADD_DISK rather than ADD_NEW_DISK, saved_raid_disk isn't initialised properly, and the drive can be included in the array without a resync. Signed-off-by: Adrian Bunk

Make 'repair' actually work for raid1.

2007-02-03T00:56:23Z

When 'repair' finds a block that is different one the various parts of the mirror. it is meant to write a chosen good version to the others. However it currently writes out the original data to each. The memcpy to make all the data the same is missing. Also correct a test so that 'repair' causes a repair, rather than anything other then 'repair'. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk

md: Fix md grow/size code to correctly find the maximum available space

2006-12-15T00:48:58Z

An md array can be asked to change the amount of each device that it is using, and in particular can be asked to use the maximum available space. This currently only works if the first device is not larger than the rest. As 'size' gets changed and so 'fit' becomes wrong. So check if a 'fit' is required early and don't corrupt it. Signed-off-by: Doug Ledford Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk

dm crypt: Fix data corruption with dm-crypt over RAID5

2006-12-15T00:21:59Z

Fix corruption issue with dm-crypt on top of software raid5. Cancelled readahead bio's that report no error, just have BIO_UPTODATE cleared were reported as successful reads to the higher layers (and leaving random content in the buffer cache). Already fixed in 2.6.19. Signed-off-by: Christophe Saout Signed-off-by: Adrian Bunk

dm snapshot: fix metadata writing when suspending

2006-12-14T22:09:07Z

When suspending a device-mapper device, dm_suspend() sleeps until all necessary I/O is completed. This state is triggered by a callback from persistent_commit(). But some I/O can still be issued *after* the callback (to prepare the next metadata area for use if the current one is full). This patch delays the callback until after that I/O is complete. Signed-off-by: Mark McLoughlin Signed-off-by: Alasdair G Kergon Signed-off-by: Adrian Bunk

dm: Fix deadlock under high i/o load in raid1 setup.

2006-12-14T22:08:32Z

On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid, we experienced frequent deadlock of the system under high i/o load. 'cat /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly after a few GB, 'cp' would be left in 'D' state along with kjournald and kmirrord. The functions cp and kjournald were blocked in did vary, but kmirrord's wchan always pointed to 'mempool_alloc()'. We've seen this pattern on 2.6.15 and 2.6.17 kernels. http://lkml.org/lkml/2005/4/20/142 indicates that this problem has been around even before. So much for the facts, here's my interpretation: mempool_alloc() first tries to atomically allocate the requested memory, or falls back to hand out preallocated chunks from the mempool. If both fail, it puts the calling process (kmirrord in this case) on a private waitqueue until somebody refills the pool. Where the only 'somebody' is kmirrord itself, so we have a deadlock. I worked around this problem by falling back to a (blocking) kmalloc when before kmirrord would have ended up on the waitqueue. This defeats part of the benefits of using the mempool, but at least keeps the system running. And it could be done with a two-line change. Note that mempool_alloc() clears the GFP_NOIO flag internally, and only uses it to decide whether to wait or return an error if immediate allocation fails, so the attached patch doesn't change behaviour in the non-deadlocking case. Path is against current git (2.6.18-rc4), but should apply to earlier versions as well. I've tested on 2.6.15, where this patch makes the difference between random lockup and a stable system. Signed-off-by: Daniel Kobras Acked-by: Alasdair G Kergon Signed-off-by: Adrian Bunk