Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 9月, 2008 1 次提交
    • N
      Remove invalidate_partition call from do_md_stop. · 271f5a9b
      由 NeilBrown 提交于 
      When stopping an md array, or just switching to read-only, we
currently call invalidate_partition while holding the mddev lock.
The main reason for this is probably to ensure all dirty buffers
are flushed (invalidate_partition calls fsync_bdev).

However if any dirty buffers are found, it will almost certainly cause
a deadlock as starting writeout will require an update to the
superblock, and performing that updates requires taking the mddev
lock - which is already held.

This deadlock can be demonstrated by running "reboot -f -n" with
a root filesystem on md/raid, and some dirty buffers in memory.

All other calls to stop an array should already happen after a flush.
The normal sequence is to stop using the array (e.g. umount) which
will cause __blkdev_put to call sync_blockdev.  Then open the
array and issue the STOP_ARRAY ioctl while the buffers are all still
clean.

So this invalidate_partition is normally a no-op, except for one case
where it will cause a deadlock.

So remove it.

This patch possibly addresses the regression recored in
   http://bugzilla.kernel.org/show_bug.cgi?id=11460
and
   http://bugzilla.kernel.org/show_bug.cgi?id=11452

though it isn't yet clear how it ever worked.
Signed-off-by: NNeilBrown <neilb@suse.de>
      271f5a9b
  3. 08 8月, 2008 1 次提交
  5. 05 8月, 2008 6 次提交
    • N
      Allow raid10 resync to happening in larger chunks. · 0310fa21
      由 NeilBrown 提交于 
      The raid10 resync/recovery code currently limits the amount of
in-flight resync IO to 2Meg.  This was copied from raid1 where
it seems quite adequate.  However for raid10, some layouts require
a bit of seeking to perform a resync, and allowing a larger buffer
size means that the seeking can be significantly reduced.

There is probably no real need to limit the amount of in-flight
IO at all.  Any shortage of memory will naturally reduce the
amount of buffer space available down to a set minimum, and any
concurrent normal IO will quickly cause resync IO to back off.

The only problem would be that normal IO has to wait for all resync IO
to finish, so a very large amount of resync IO could cause unpleasant
latency when normal IO starts up.

So: increase RESYNC_DEPTH to allow 32Meg of buffer (if memory is
available) which seems to be a good amount.  Also reduce the amount
of memory reserved as there is no need to keep 2Meg just for resync if
memory is tight.

Thanks to Keld for the suggestion.

Cc: Keld Jørn Simonsen <keld@dkuug.dk>
Signed-off-by: NNeilBrown <neilb@suse.de>
      0310fa21
    • N
      Allow faulty devices to be removed from a readonly array. · c89a8eee
      由 NeilBrown 提交于 
      Removing faulty devices from an array is a two stage process.
First the device is moved from being a part of the active array
to being similar to a spare device.  Then it can be removed
by a request from user space.

The first step is currently not performed for read-only arrays,
so the second step can never succeed.

So allow readonly arrays to remove failed devices (which aren't
blocked).
Signed-off-by: NNeilBrown <neilb@suse.de>
      c89a8eee
    • N
      Don't let a blocked_rdev interfere with read request in raid5/6 · ac4090d2
      由 NeilBrown 提交于 
      When we have externally managed metadata, we need to mark a failed
device as 'Blocked' and not allow any writes until that device
have been marked as faulty in the metadata and the Blocked flag has
been removed.

However it is perfectly OK to allow read requests when there is a
Blocked device, and with a readonly array, there may not be any
metadata-handler watching for blocked devices.

So in raid5/raid6 only allow a Blocked device to interfere with
Write request or resync.  Read requests go through untouched.

raid1 and raid10 already differentiate between read and write
properly.
Signed-off-by: NNeilBrown <neilb@suse.de>
      ac4090d2
    • N
      Fail safely when trying to grow an array with a write-intent bitmap. · dba034ee
      由 NeilBrown 提交于 
      We cannot currently change the size of a write-intent bitmap.
So if we change the size of an array which has such a bitmap, it
tries to set bits beyond the end of the bitmap.

For now, simply reject any request to change the size of an array
which has a bitmap.  mdadm can remove the bitmap and add a new one
after the array has changed size.
Signed-off-by: NNeilBrown <neilb@suse.de>
      dba034ee
    • N
      Restore force switch of md array to readonly at reboot time. · 2b25000b
      由 NeilBrown 提交于 
      A recent patch allowed do_md_stop to know whether it was being called
via an ioctl or not, and thus where to allow for an extra open file
descriptor when checking if it is in use.
This broke then switch to readonly performed by the shutdown notifier,
which needs to work even when the array is still (apparently) active
(as md doesn't get told when the filesystem becomes readonly).

So restore this feature by pretending that there can be lots of
file descriptors open, but we still want do_md_stop to switch to
readonly.
Signed-off-by: NNeilBrown <neilb@suse.de>
      2b25000b
    • N
      Make writes to md/safe_mode_delay immediately effective. · 19052c0e
      由 NeilBrown 提交于 
      If we reduce the 'safe_mode_delay', it could still wait for the old
delay to completely expire before doing anything about safe_mode.
Thus the effect if the change is delayed.

To make the effect more immediate, run the timeout function
immediately if the delay was reduced.  This may cause it to run
slightly earlier that required, but that is the safer option.
Signed-off-by: NNeilBrown <neilb@suse.de>
      19052c0e
  7. 02 8月, 2008 1 次提交
  9. 01 8月, 2008 2 次提交
  11. 29 7月, 2008 2 次提交
  13. 27 7月, 2008 1 次提交
  15. 24 7月, 2008 3 次提交
  17. 21 7月, 2008 19 次提交
  19. 15 7月, 2008 1 次提交
  21. 11 7月, 2008 3 次提交