- 09 Nov, 2007 1 commit
-
-
Alan D. Brunelle authored
Added blk_unplug interface, allowing all invocations of unplugs to result in a generated blktrace UNPLUG. Signed-off-by:
Alan D. Brunelle <Alan.Brunelle@hp.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
- 19 Oct, 2007 1 commit
-
-
Jan Engelhardt authored
* Convert files to UTF-8. * Also correct some people's names (one example is Eißfeldt, which was found in a source file. Given that the author used an ß at all in a source file indicates that the real name has in fact a 'ß' and not an 'ss', which is commonly used as a substitute for 'ß' when limited to 7bit.) * Correct town names (Goettingen -> Göttingen) * Update Eberhard Mönkeberg's address (http://lkml.org/lkml/2007/1/8/313 ) Signed-off-by:Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
Adrian Bunk <bunk@kernel.org>
-
- 17 Oct, 2007 1 commit
-
-
NeilBrown authored
Whenever a read error is found, we should attempt to overwrite with correct data to 'fix' it. However when do a 'check' pass (which compares data blocks that are successfully read, but doesn't normally overwrite) we don't do that. We should. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 16 Oct, 2007 1 commit
-
-
Jens Axboe authored
Then we can get rid of ->issue_flush_fn() and all the driver private implementations of that. Signed-off-by:
-
- 10 Oct, 2007 1 commit
-
-
NeilBrown authored
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:
-
- 22 Aug, 2007 2 commits
-
-
NeilBrown authored
When a raid1 array is reshaped (number of drives changed), the list of devices is compacted, so that slots for missing devices are filled with working devices from later slots. This requires the "rd%d" symlinks in sysfs to be updated. Signed-off-by:
-
NeilBrown authored
Commit 17571284 was slightly bad. If an array has a write-intent bitmap, and you remove a drive, then readd it, only the changed parts should be resynced. However after the above commit, this only works if the array has not been shut down and restarted. This is because it sets 'fullsync' at little more often than it should. This patch is more careful. Signed-off-by:
-
- 24 Jul, 2007 1 commit
-
-
Jens Axboe authored
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:
-
- 17 Jul, 2007 1 commit
-
-
NeilBrown authored
bitmap_unplug only ever returns 0, so it may as well be void. Two callers try to print a message if it returns non-zero, but that message is already printed by bitmap_file_kick. write_page returns an error which is not consistently checked. It always causes BITMAP_WRITE_ERROR to be set on an error, and that can more conveniently be checked. When the return of write_page is checked, an error causes bitmap_file_kick to be called - so move that call into write_page - and protect against recursive calls into bitmap_file_kick. bitmap_update_sb returns an error that is never checked. So make these 'void' and be consistent about checking the bit. Signed-off-by:
-
- 16 Jun, 2007 1 commit
-
-
Mike Accetta authored
If raid1/repair (which reads all block and fixes any differences it finds) hits a read error, it doesn't reset the bio for writing before writing correct data back, so the read error isn't fixed, and the device probably gets a zero-length write which it might complain about. Signed-off-by:
-
- 10 May, 2007 1 commit
-
-
NeilBrown authored
When a raid1 has only one working drive, we want read error to propagate up to the filesystem as there is no point failing the last drive in an array. Currently the code perform this check is racy. If a write and a read a both submitted to a device on a 2-drive raid1, and the write fails followed by the read failing, the read will see that there is only one working drive and will pass the failure up, even though the one working drive is actually the *other* one. So, tighten up the locking. Signed-off-by:
-
- 09 May, 2007 2 commits
-
-
Linus Torvalds authored
This reverts commit 5b479c91 . Quoth Neil Brown: "It causes an oops when auto-detecting raid arrays, and it doesn't seem easy to fix. The array may not be 'open' when do_md_run is called, so bdev->bd_disk might be NULL, so bd_set_size can oops. This whole approach of opening an md device before it has been assembled just seems to get more and more painful. I think I'm going to have to come up with something clever to provide both backward comparability with usage expectation, and sane integration into the rest of the kernel." Signed-off-by:
-
NeilBrown authored
md currently uses ->media_changed to make sure rescan_partitions is call on md array after they are assembled. However that doesn't happen until the array is opened, which is later than some people would like. So use blkdev_ioctl to do the rescan immediately that the array has been assembled. This means we can remove all the ->change infrastructure as it was only used to trigger a partition rescan. Signed-off-by:
-
- 26 Jan, 2007 2 commits
-
-
NeilBrown authored
If a GFP_KERNEL allocation is attempted in md while the mddev_lock is held, it is possible for a deadlock to eventuate. This happens if the array was marked 'clean', and the memalloc triggers a write-out to the md device. For the writeout to succeed, the array must be marked 'dirty', and that requires getting the mddev_lock. So, before attempting a GFP_KERNEL allocation while holding the lock, make sure the array is marked 'dirty' (unless it is currently read-only). Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
NeilBrown authored
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. Signed-off-by:
-
- 11 Jan, 2007 1 commit
-
-
Lars Ellenberg authored
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. Acked-by:
Lars Ellenberg <lars@linbit.com> Acked-by:
Linus Torvalds <torvalds@osdl.org>
-
- 13 Dec, 2006 1 commit
-
-
NeilBrown authored
Thanks Jens for alerting me to this. Cc: Jens Axboe <jens.axboe@oracle.com> Cc: <raziebe@gmail.com> Signed-off-by:
-
- 10 Dec, 2006 1 commit
-
-
NeilBrown authored
Fix few bugs that meant that: - superblocks weren't alway written at exactly the right time (this could show up if the array was not written to - writting to the array causes lots of superblock updates and so hides these errors). - restarting device recovery after a clean shutdown (version-1 metadata only) didn't work as intended (or at all). 1/ Ensure superblock is updated when a new device is added. 2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync. The body of this if takes one of two branches depending on whether MD_RECOVERY_SYNC is set, so testing it in the clause of the if is wrong. 3/ Flag superblock for updating after a resync/recovery finishes. 4/ If we find the neeed to restart a recovery in the middle (version-1 metadata only) make sure a full recovery (not just as guided by bitmaps) does get done. Signed-off-by:
-
- 28 Oct, 2006 1 commit
-
-
Randy Dunlap authored
drivers/md/raid1.c:1479: warning: long long unsigned int format, long unsigned int arg (arg 4) drivers/md/raid10.c:1475: warning: long long unsigned int format, long unsigned int arg (arg 4) Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
- 03 Oct, 2006 5 commits
-
-
NeilBrown authored
raid1, raid10 and multipath don't report their 'congested' status through bdi_*_congested, but should. This patch adds the appropriate functions which just check the 'congested' status of all active members (with appropriate locking). raid1 read_balance should be modified to prefer devices where bdi_read_congested returns false. Then we could use the '&' branch rather than the '|' branch. However that should would need some benchmarking first to make sure it is actually a good idea. Signed-off-by:
-
NeilBrown authored
The error handling routines don't use proper locking, and so two concurrent errors could trigger a problem. So: - use test-and-set and test-and-clear to synchonise the In_sync bits with the ->degraded count - use the spinlock to protect updates to the degraded count (could use an atomic_t but that would be a bigger change in code, and isn't really justified) - remove un-necessary locking in raid5 Signed-off-by: -
NeilBrown authored
It is equivalent to conf->raid_disks - conf->mddev->degraded. Signed-off-by:
-
NeilBrown authored
raid1d has toooo many nested block, so take the fix_read_error functionality out into a separate function. Signed-off-by:
-
NeilBrown authored
Instead of magic numbers (0,1,2,3) in sb_dirty, we have some flags instead: MD_CHANGE_DEVS Some device state has changed requiring superblock update on all devices. MD_CHANGE_CLEAN The array has transitions from 'clean' to 'dirty' or back, requiring a superblock update on active devices, but possibly not on spares MD_CHANGE_PENDING A superblock update is underway. We wait for an update to complete by waiting for all flags to be clear. A flag can be set at any time, even during an update, without risk that the change will be lost. Stop exporting md_update_sb - isn't needed. Signed-off-by:
-
- 01 Sep, 2006 1 commit
-
-
NeilBrown authored
We need to be careful when referencing mirrors[i].rdev. It can disappear under us at various times. So: fix a couple of problem places. comment a couple of non-problem places move an 'atomic_add' which deferences rdev down a little way to some where where it is sure to not be NULL. Signed-off-by:
-
- 27 Aug, 2006 1 commit
-
-
NeilBrown authored
A recent patch broke the ability to do a user-request check of a raid1. This patch fixes the breakage and also moves a comment that was dislocated by the same patch. Signed-off-by:
-
- 10 Jul, 2006 2 commits
-
-
NeilBrown authored
This is generally useful, but particularly helps see if it is the same sector that always needs correcting, or different ones. [akpm@osdl.org: fix printk warnings] Signed-off-by:
-
NeilBrown authored
Though it rarely matters, we should be using 's' rather than r1_bio->sector here. Signed-off-by:
-
- 26 Jun, 2006 3 commits
-
-
NeilBrown authored
When an array has a bitmap, a device can be removed and re-added and only blocks changes since the removal (as recorded in the bitmap) will be resynced. It should be possible to do a similar thing to arrays without bitmaps. i.e. if a device is removed and re-added and *no* changes have been made in the interim, then the add should not require a resync. This patch allows that option. This means that when assembling an array one device at a time (e.g. during device discovery) the array can be enabled read-only as soon as enough devices are available, but extra devices can still be added without causing a resync. Signed-off-by:
-
NeilBrown authored
For a while we have had checkpointing of resync. The version-1 superblock allows recovery to be checkpointed as well, and this patch implements that. Due to early carelessness we need to add a feature flag to signal that the recovery_offset field is in use, otherwise older kernels would assume that a partially recovered array is in fact fully recovered. Signed-off-by:
-
NeilBrown authored
A recent change made this goto unnecessary, so reformat the code to make it clearer what is happening. Signed-off-by:
-
- 01 May, 2006 3 commits
-
-
NeilBrown authored
When retrying a failed BIO_RW_BARRIER request, we need to keep the reference in ->nr_pending over the whole retry. Currently, we only hold the reference if the failed request is the *last* one to finish - which is silly, because it would normally be the first to finish. So move the rdev_dec_pending call up into the didn't-fail branch. As the rdev isn't used in the later code, calling rdev_dec_pending earlier doesn't hurt. Signed-off-by:
-
NeilBrown authored
Move the test for 'do barrier work' down a bit so that if the first write to a raid1 is a BIO_RW_BARRIER write, the checking done by superblock writes will cause the right thing to happen. Signed-off-by:
-
NeilBrown authored
Because that is what you get if a BIO_RW_BARRIER isn't supported! Signed-off-by:
-
- 31 Mar, 2006 2 commits
-
-
Eric Sesterhenn authored
this changes if() BUG(); constructs to BUG_ON() which is cleaner and can better optimized away Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
NeilBrown authored
Currently a device failure during recovery leaves bits set in the bitmap. This normally isn't a problem as the offending device will be rejected because of errors. However if device re-adding is being used with non-persistent bitmaps, this can be a problem. Signed-off-by:
-
- 27 Mar, 2006 3 commits
-
-
NeilBrown authored
When retrying a write due to barrier failure, we don't reset 'remaining', so it goes negative and never hits 0 again. Signed-off-by:
-
NeilBrown authored
check_reshape checks validity and does things that can be done instantly - like adding devices to raid1. start_reshape initiates a restriping process to convert the whole array. Signed-off-by:
-
NeilBrown authored
We allow the superblock to record an 'old' and a 'new' geometry, and a position where any conversion is up to. The geometry allows for changing chunksize, layout and level as well as number of devices. When using verion-0.90 superblock, we convert the version to 0.91 while the conversion is happening so that an old kernel will refuse the assemble the array. For version-1, we use a feature bit for the same effect. When starting an array we check for an incomplete reshape and restart the reshape process if needed. If the reshape stopped at an awkward time (like when updating the first stripe) we refuse to assemble the array, and let user-space worry about it. Signed-off-by:
-
- 09 Mar, 2006 1 commit
-
-
NeilBrown authored
- wrong test for 'is this a BARRIER bio' - not freeing on all possible paths. - using r1_bio after freeing it. Signed-off-by:
-
