Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 12月, 2009 8 次提交
    • N
      md: add honouring of suspend_{lo,hi} to raid1. · 6eef4b21
      由 NeilBrown 提交于 
      This will allow us to stop writeout to portions of the array
while  they are resynced by someone else - e.g. another node in
a cluster.
Signed-off-by: NNeilBrown <neilb@suse.de>
      6eef4b21
    • N
      md/raid5: don't complete make_request on barrier until writes are scheduled · 729a1866
      由 NeilBrown 提交于 
      The post-barrier-flush is sent by md as soon as make_request on the
barrier write completes.  For raid5, the data might not be in the
per-device queues yet.  So for barrier requests, wait for any
pre-reading to be done so that the request will be in the per-device
queues.

We use the 'preread_active' count to check that nothing is still in
the preread phase, and delay the decrement of this count until after
write requests have been submitted to the underlying devices.
Signed-off-by: NNeilBrown <neilb@suse.de>
      729a1866
    • N
      md: support barrier requests on all personalities. · a2826aa9
      由 NeilBrown 提交于 
      Previously barriers were only supported on RAID1.  This is because
other levels requires synchronisation across all devices and so needed
a different approach.
Here is that approach.

When a barrier arrives, we send a zero-length barrier to every active
device.  When that completes - and if the original request was not
empty -  we submit the barrier request itself (with the barrier flag
cleared) and then submit a fresh load of zero length barriers.

The barrier request itself is asynchronous, but any subsequent
request will block until the barrier completes.

The reason for clearing the barrier flag is that a barrier request is
allowed to fail.  If we pass a non-empty barrier through a striping
raid level it is conceivable that part of it could succeed and part
could fail.  That would be way too hard to deal with.
So if the first run of zero length barriers succeed, we assume all is
sufficiently well that we send the request and ignore errors in the
second run of barriers.

RAID5 needs extra care as write requests may not have been submitted
to the underlying devices yet.  So we flush the stripe cache before
proceeding with the barrier.

Note that the second set of zero-length barriers are submitted
immediately after the original request is submitted.  Thus when
a personality finds mddev->barrier to be set during make_request,
it should not return from make_request until the corresponding
per-device request(s) have been queued.

That will be done in later patches.
Signed-off-by: NNeilBrown <neilb@suse.de>
Reviewed-by: NAndre Noll <maan@systemlinux.org>
      a2826aa9
    • N
      md: don't reset curr_resync_completed after an interrupted resync · efa59339
      由 NeilBrown 提交于 
      If a resync/recovery/check/repair is interrupted for some reason, it
can be useful to know exactly where it got up to.
So in that case, do not clear curr_resync_completed.
Initialise it when starting a resync/recovery/... instead.
Signed-off-by: NNeilBrown <neilb@suse.de>
      efa59339
    • N
      md: adjust resync_min usefully when resync aborts. · c07b70ad
      由 NeilBrown 提交于 
      When a 'check' or 'repair' finished we should clear resync_min
so that a future check/repair will cover the whole array (by default).
However if it is interrupted, we should update resync_min to
where we got up to, so that when the check/repair continues it
just does the remainder of the array.
Signed-off-by: NNeilBrown <neilb@suse.de>
      c07b70ad
    • N
      md: remove sparse warning:symbol XXX was not declared. · 7820f9e1
      由 NeilBrown 提交于 
      Signed-off-by: NNeilBrown <neilb@suse.de>
      7820f9e1
    • N
      md/raid5: remove some sparse warnings. · 8553fe7e
      由 NeilBrown 提交于 
      qd_idx is previously declared and given exactly the same value!
Signed-off-by: NNeilBrown <neilb@suse.de>
      8553fe7e
    • N
      md/bitmap: protect against bitmap removal while being updated. · aa5cbd10
      由 NeilBrown 提交于 
      A write intent bitmap can be removed from an array while the
array is active.
When this happens, all IO is suspended and flushed before the
bitmap is removed.
However it is possible that bitmap_daemon_work is still running to
clear old bits from the bitmap.  If it is, it can dereference the
bitmap after it has been freed.

So introduce a new mutex to protect bitmap_daemon_work and get it
before destroying a bitmap.

This is suitable for any current -stable kernel.
Signed-off-by: NNeilBrown <neilb@suse.de>
Cc: stable@kernel.org
      aa5cbd10
  3. 13 12月, 2009 1 次提交
  5. 12 12月, 2009 31 次提交