Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 22 5月, 2012 8 次提交
    • N
      md/bitmap: separate bitmap file allocation to its own function. · d1244cb0
      由 NeilBrown 提交于 
      This will allow allocation before swapping in a new bitmap.
Signed-off-by: NNeilBrown <neilb@suse.de>
      d1244cb0
    • N
      md/bitmap: store bytes in file rather than just in last page. · 9b1215c1
      由 NeilBrown 提交于 
      This number is more generally useful, and bytes-in-last-page is
easily extracted from it.
Signed-off-by: NNeilBrown <neilb@suse.de>
      9b1215c1
    • N
      md/bitmap: move some fields of 'struct bitmap' into a 'storage' substruct. · 1ec885cd
      由 NeilBrown 提交于 
      This new 'struct bitmap_storage' reflects the external storage of the
bitmap.
Having this clearly defined will make it easier to change the storage
used while the array is active.
Signed-off-by: NNeilBrown <neilb@suse.de>
      1ec885cd
    • N
      md/bitmap: change *_page_attr() to take a page number, not a page. · d189122d
      由 NeilBrown 提交于 
      Most often we have the page number, not the page.  And that is what
the  *_page_attr() functions really want.  So change the arguments to
take that number.
Signed-off-by: NNeilBrown <neilb@suse.de>
      d189122d
    • N
      md/bitmap: centralise allocation of bitmap file pages. · 27581e5a
      由 NeilBrown 提交于 
      Instead of allocating pages in read_sb_page, read_page and
bitmap_read_sb, allocate them all in bitmap_init_from disk.

Also replace the hack of calling "attach_page_buffers(page, NULL)" to
ensure that free_buffer() won't complain, by putting a test for
PagePrivate in free_buffer().
Signed-off-by: NNeilBrown <neilb@suse.de>
      27581e5a
    • N
      md/bitmap: allow a bitmap with no backing storage. · ef99bf48
      由 NeilBrown 提交于 
      An md bitmap comprises two parts
 - internal counting of active writes per 'chunk'.
 - external storage of whether there are any active writes on
   each chunk

The second requires the first, but the first doesn't require the
second.

Not having backing storage means that the bitmap cannot expedite
resync after a crash, but it still allows us to expedite the recovery
of a recently-removed device.

So: allow a bitmap to exist even if there is no backing device.
In that case we default to 128M chunks.

A particular value of this is that we can remove and re-add a bitmap
(possibly of a different granularity) on a degraded array, and not
lose the information needed to fast-recover the missing device.

We don't actually activate these bitmaps yet - that will come
in a later patch.
Signed-off-by: NNeilBrown <neilb@suse.de>
      ef99bf48
    • N
      md/bitmap: add new 'space' attribute for bitmaps. · 6409bb05
      由 NeilBrown 提交于 
      If we are to allow bitmaps to be resized when the array is resized,
we need to know how much space there is.

So create an attribute to store this information and set appropriate
defaults.

It can be set more precisely via sysfs, or future metadata extensions
may allow it to be recorded.
Signed-off-by: NNeilBrown <neilb@suse.de>
      6409bb05
    • N
      md/bitmap: disentangle two different 'pending' flags. · bf07bb7d
      由 NeilBrown 提交于 
      There are two different 'pending' concepts in the handling of the
write intent bitmap.

Firstly, a 'page' from the bitmap (which container PAGE_SIZE*8 bits)
may have changes (bits cleared) that should be written in due course.
There is no hurry for these and the page will transition from
PENDING to NEEDWRITE and will then be written, though if it ever
becomes DIRTY it will be written much sooner and PENDING will be
cleared.

Secondly, a page of counters - which contains PAGE_SIZE/2 counters, one
for each bit, can usefully have a 'pending' flag which indicates if
any of the counters are low (2 or 1) and ready to be processed by
bitmap_daemon_work().  If this flag is clear we can skip the whole
page.

These two concepts are currently combined in the bitmap-file flag.
This causes a tighter connection between the counters and the bitmap
file than I would like - as I want to add some flexibility to the
bitmap file.

So introduce a new flag with the page-of-counters, and rewrite
bitmap_daemon_work() so that it handles the two different 'pending'
concepts separately.

This also allows us to clear BITMAP_PAGE_PENDING when we write out
a dirty page, which may occasionally reduce the number of times we
write a page.
Signed-off-by: NNeilBrown <neilb@suse.de>
      bf07bb7d
  3. 04 5月, 2012 1 次提交
  5. 12 4月, 2012 2 次提交
  7. 20 3月, 2012 1 次提交
  9. 19 3月, 2012 7 次提交
  11. 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
  13. 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
  15. 11 10月, 2011 3 次提交
  17. 07 10月, 2011 1 次提交
  19. 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
  21. 27 7月, 2011 2 次提交
  23. 09 6月, 2011 4 次提交
  25. 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
  27. 24 3月, 2011 1 次提交
  29. 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
  31. 14 1月, 2011 1 次提交
    • 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