Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 4月, 2012 2 次提交
  3. 20 3月, 2012 1 次提交
  5. 19 3月, 2012 7 次提交
  7. 23 12月, 2011 3 次提交
    • N
      md/bitmap: be more consistent when setting new bits in memory bitmap. · 915c420d
      由 NeilBrown 提交于 
      For each active region corresponding to a bit in the bitmap with have
a 14bit counter (and some flags).
This counts
   number of active writes + bit in the on-disk bitmap + delay-needed.

The "delay-needed" is because we always want a delay before clearing a
bit.  So the number here is normally number of active writes plus 2.
If there have been no writes for a while, we drop to 1.
If still no writes we clear the bit and drop to 0.

So for consistency, when setting bit from the on-disk bitmap or by
request from user-space it is best to set the counter to '2' to start
with.

In particular we might also set the NEEDED_MASK flag at this time, and
in all other cases NEEDED_MASK is only set when the counter is 2 or
more.
Signed-off-by: NNeilBrown <neilb@suse.de>
      915c420d
    • N
      md/bitmap: daemon_work cleanup. · 2e61ebbc
      由 NeilBrown 提交于 
      We have a variable 'mddev' in this function, but repeatedly get the
same value by dereferencing bitmap->mddev.
There is room for simplification here...
Signed-off-by: NNeilBrown <neilb@suse.de>
      2e61ebbc
    • N
      md/bitmap: It is OK to clear bits during recovery. · 961902c0
      由 NeilBrown 提交于 
      commit d0a4bb49 introduced a
regression which is annoying but fairly harmless.

When writing to an array that is undergoing recovery (a spare
in being integrated into the array), writing to the array will
set bits in the bitmap, but they will not be cleared when the
write completes.

For bits covering areas that have not been recovered yet this is not a
problem as the recovery will clear the bits.  However bits set in
already-recovered region will stay set and never be cleared.
This doesn't risk data integrity.  The only negatives are:
 - next time there is a crash, more resyncing than necessary will
   be done.
 - the bitmap doesn't look clean, which is confusing.

While an array is recovering we don't want to update the
'events_cleared' setting in the bitmap but we do still want to clear
bits that have very recently been set - providing they were written to
the recovering device.

So split those two needs - which previously both depended on 'success'
and always clear the bit of the write went to all devices.
Signed-off-by: NNeilBrown <neilb@suse.de>
      961902c0
  9. 23 11月, 2011 1 次提交
    • N
      md/lock: ensure updates to page_attrs are properly locked. · 7c8f4247
      由 NeilBrown 提交于 
      Page attributes are set using __set_bit rather than set_bit as
it normally called under a spinlock so the extra atomicity is not
needed.

However there are two places where we might set or clear page
attributes without holding the spinlock.
So add the spinlock in those cases.

This might be the cause of occasional reports that bits a aren't
getting clear properly - theory is that BITMAP_PAGE_PENDING gets lost
when BITMAP_PAGE_NEEDWRITE is set or cleared.  This is an
inconvenience, not a threat to data safety.
Signed-off-by: NNeilBrown <neilb@suse.de>
      7c8f4247
  11. 11 10月, 2011 3 次提交
  13. 07 10月, 2011 1 次提交
  15. 21 9月, 2011 2 次提交
    • N
      md/bitmap: improve handling of 'allclean'. · 2585f3ef
      由 NeilBrown 提交于 
      The 'allclean' flag is used to cache the fact that there is nothing to
do, so we can avoid waking up and scanning the bitmap regularly.

The two sorts of pages that might need the attention of the bitmap
daemon are BITMAP_PAGE_PENDING and BITMAP_PAGE_NEEDWRITE pages.

So make sure allclean reflects exactly when there are none of those.
So:
  set it before scanning all pages with either bit set.
  clear it whenever these bits are set
  clear it when we desire not to clear one of these bits.
  don't clear it any other time.
Signed-off-by: NNeilBrown <neilb@suse.de>
      2585f3ef
    • N
      md/bitmap: rename and tidy up BITMAP_PAGE_CLEAN · 5a537df4
      由 NeilBrown 提交于 
      The flag 'BITMAP_PAGE_CLEAN' has a confusing name as it doesn't mean
that the page is clean, but rather that there are counters in the page
which allow bits in the bitmap to be cleared - i.e. maybe cleaning can
happen.

So change it to BITMAP_PAGE_PENDING and fix some irregularities:
 - Don't set it in bitmap_init_from_disk as bitmap_set_memory_bits
   sets it when needed
 - in bitmap_daemon_work, if we find a counter that is '1', but
   need_sync is set, then set BITMAP_PAGE_PENDING again (it was
   recently cleared) to ensure we don't forget about this bit.

Signed-off-by: NeilBrown <neilb@suse.de>
      5a537df4
  17. 27 7月, 2011 2 次提交
  19. 09 6月, 2011 4 次提交
  21. 11 5月, 2011 1 次提交
    • N
      md/bitmap: fix saving of events_cleared and other state. · 8258c532
      由 NeilBrown 提交于 
      If a bitmap is found to be 'stale' the events_cleared value
is set to match 'events'.
However if the array is degraded this does not get stored on disk.
This can subsequently lead to incorrect behaviour.

So change bitmap_update_sb to always update events_cleared in the
superblock from the known events_cleared.
For neatness also set ->state from ->flags.
This requires updating ->state whenever we update ->flags, which makes
sense anyway.

This is suitable for any active -stable release.

cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>
      8258c532
  23. 24 3月, 2011 1 次提交
  25. 10 3月, 2011 2 次提交
    • J
      block: kill off REQ_UNPLUG · 721a9602
      由 Jens Axboe 提交于 
      With the plugging now being explicitly controlled by the
submitter, callers need not pass down unplugging hints
to the block layer. If they want to unplug, it's because they
manually plugged on their own - in which case, they should just
unplug at will.
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      721a9602
    • J
      block: remove per-queue plugging · 7eaceacc
      由 Jens Axboe 提交于 
      Code has been converted over to the new explicit on-stack plugging,
and delay users have been converted to use the new API for that.
So lets kill off the old plugging along with aops->sync_page().
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      7eaceacc
  27. 14 1月, 2011 3 次提交
    • N
      md: Don't let implementation detail of curr_resync leak out through sysfs. · 75d3da43
      由 NeilBrown 提交于 
      mddev->curr_resync has artificial values of '1' and '2' which are used
by the code which ensures only one resync is happening at a time on
any given device.

These values are internal and should never be exposed to user-space
(except when translated appropriately as in the 'pending' status in
/proc/mdstat).

Unfortunately they are as ->curr_resync is assigned to
->curr_resync_completed and that value is directly visible through
sysfs.

So change the assignments to ->curr_resync_completed to get the same
valued from elsewhere in a form that doesn't have the magic '1' or '2'
values.
Signed-off-by: NNeilBrown <neilb@suse.de>
      75d3da43
    • J
      md: separate meta and data devs · a6ff7e08
      由 Jonathan Brassow 提交于 
      Allow the metadata to be on a separate device from the
data.

This doesn't mean the data and metadata will by on separate
physical devices - it simply gives device-mapper and userspace
tools more flexibility.
Signed-off-by: NNeilBrown <neilb@suse.de>
      a6ff7e08
    • J
      md-new-param-to_sync_page_io · ccebd4c4
      由 Jonathan Brassow 提交于 
      Add new parameter to 'sync_page_io'.

The new parameter allows us to distinguish between metadata and data
operations.  This becomes important later when we add the ability to
use separate devices for data and metadata.
Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
      ccebd4c4
  29. 29 10月, 2010 1 次提交
  31. 28 10月, 2010 2 次提交
  33. 07 10月, 2010 1 次提交
  35. 30 8月, 2010 1 次提交
    • N
      md: resolve confusion of MD_CHANGE_CLEAN · 070dc6dd
      由 NeilBrown 提交于 
      MD_CHANGE_CLEAN is used for two different purposes and this leads to
confusion.
One of the purposes is largely mirrored by MD_CHANGE_PENDING which is
not used for anything else, so have MD_CHANGE_PENDING take over that
purpose fully.

The two purposes are:
 1/ tell md_update_sb that an update is needed and that it is just a
   clean/dirty transition.
 2/ tell user-space that an transition from clean to dirty is pending
    (something wants to write), and tell te kernel (by clearin the
    flag) that the transition is OK.

The first purpose remains wit MD_CHANGE_CLEAN, the second is moved
fully to MD_CHANGE_PENDING.

This means that various places which conditionally set or cleared
MD_CHANGE_CLEAN no longer need to be conditional.
Signed-off-by: NNeilBrown <neilb@suse.de>
      070dc6dd
  37. 26 7月, 2010 2 次提交