2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-02-08 18:51:30 +01:00
|
|
|
|
2005-09-09 16:23:56 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2011-09-16 02:31:11 -04:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
2009-12-14 18:01:06 -08:00
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:58:33 -04:00
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2009-12-14 12:50:05 +11:00
|
|
|
|
2008-10-15 09:09:21 +11:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2016-11-18 09:44:08 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-03-31 14:27:03 +11:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-09-21 15:30:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2014-06-07 02:39:37 -05:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-10 00:26:54 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:18 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2009-11-16 03:11:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2009-11-16 03:11:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-05 14:34:02 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:18 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-11-05 14:34:02 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:18 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-05 14:34:02 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-09-21 17:01:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
2017-06-18 14:38:59 +10:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 15:34:55 -07:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
|
|
|
|
|
2017-06-23 09:19:49 -07:00
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:43 -08:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:10 -08:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-21 10:23:35 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-05 10:41:16 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-03-25 16:20:56 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-02-07 19:21:48 -05:00
|
|
|
|
2015-04-03 08:44:47 +08:00
|
|
|
|
2010-03-25 16:20:56 +11:00
|
|
|
|
2017-06-18 14:38:57 +10:00
|
|
|
|
2015-04-23 22:37:18 -07:00
|
|
|
|
2016-01-04 16:16:58 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2015-11-05 10:41:16 -07:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2013-02-21 13:28:09 +11:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2015-11-05 10:41:16 -07:00
|
|
|
|
2013-02-21 13:28:09 +11:00
|
|
|
|
2010-03-25 16:20:56 +11:00
|
|
|
|
2011-02-07 19:21:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-25 16:52:38 -07:00
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2017-09-21 10:23:35 -07:00
|
|
|
|
|
|
|
|
|
2010-03-25 16:20:56 +11:00
|
|
|
|
2015-04-03 08:44:47 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-25 16:20:56 +11:00
|
|
|
|
2015-11-05 10:41:16 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-04-06 14:23:02 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
2010-04-06 14:23:02 +10:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2016-05-03 19:43:57 +02:00
|
|
|
|
2015-12-18 15:19:16 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2017-06-05 16:49:39 +10:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2012-05-16 04:06:14 -05:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2015-12-18 15:19:16 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2011-06-07 17:49:36 -05:00
|
|
|
|
2012-05-22 13:55:29 +10:00
|
|
|
|
2011-06-07 17:49:36 -05:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-09-23 18:10:29 +10:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-23 18:10:29 +10:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 16:04:25 +11:00
|
|
|
|
|
|
|
|
|
2010-12-09 16:17:51 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2010-12-09 16:04:25 +11:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:26:59 +10:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2016-11-01 07:40:10 -06:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2016-06-05 14:31:41 -05:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 16:04:25 +11:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2017-09-21 09:55:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2017-09-21 09:55:28 -07:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2010-12-09 16:17:51 +11:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:49 +11:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-04 00:57:25 -07:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-07-03 14:34:23 -07:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2009-12-30 12:08:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 15:49:46 +11:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
2017-07-03 14:34:23 -07:00
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
|
|
|
|
|
2017-07-03 14:34:23 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-07-24 18:19:58 -04:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-24 18:19:58 -04:00
|
|
|
|
|
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-02-16 13:58:51 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:32 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 15:55:30 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-04-14 17:15:37 +10:00
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
2010-04-14 17:15:37 +10:00
|
|
|
|
|
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-14 17:15:37 +10:00
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-19 16:48:26 +11:00
|
|
|
|
|
|
|
|
|
2011-09-21 15:30:20 +10:00
|
|
|
|
|
|
|
|
|
2005-08-22 13:11:08 -07:00
|
|
|
|
2011-09-21 15:30:20 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-04-14 10:43:55 -05:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:55 -05:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2008-07-11 22:02:20 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-22 13:54:30 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-06 12:19:22 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-22 13:54:30 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
|
|
|
|
|
[PATCH] md: support BIO_RW_BARRIER for md/raid1
We can only accept BARRIER requests if all slaves handle
barriers, and that can, of course, change with time....
So we keep track of whether the whole array seems safe for barriers,
and also whether each individual rdev handles barriers.
We initially assumes barriers are OK.
When writing the superblock we try a barrier, and if that fails, we flag
things for no-barriers. This will usually clear the flags fairly quickly.
If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
resubmit, so introduce function "md_super_wait" which waits for requests to
finish, and retries ENOTSUPP requests without the barrier flag.
When writing the real raid1, write requests which were BIO_RW_BARRIER but
which aresn't supported need to be retried. So raid1d is enhanced to do this,
and when any bio write completes (i.e. no retry needed) we remove it from the
r1bio, so that devices needing retry are easy to find.
We should hardly ever get -ENOTSUPP errors when writing data to the raid.
It should only happen if:
1/ the device used to support BARRIER, but now doesn't. Few devices
change like this, though raid1 can!
or
2/ the array has no persistent superblock, so there was no opportunity to
pre-test for barriers when writing the superblock.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:34 -08:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
[PATCH] md: support BIO_RW_BARRIER for md/raid1
We can only accept BARRIER requests if all slaves handle
barriers, and that can, of course, change with time....
So we keep track of whether the whole array seems safe for barriers,
and also whether each individual rdev handles barriers.
We initially assumes barriers are OK.
When writing the superblock we try a barrier, and if that fails, we flag
things for no-barriers. This will usually clear the flags fairly quickly.
If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
resubmit, so introduce function "md_super_wait" which waits for requests to
finish, and retries ENOTSUPP requests without the barrier flag.
When writing the real raid1, write requests which were BIO_RW_BARRIER but
which aresn't supported need to be retried. So raid1d is enhanced to do this,
and when any bio write completes (i.e. no retry needed) we remove it from the
r1bio, so that devices needing retry are easy to find.
We should hardly ever get -ENOTSUPP errors when writing data to the raid.
It should only happen if:
1/ the device used to support BARRIER, but now doesn't. Few devices
change like this, though raid1 can!
or
2/ the array has no persistent superblock, so there was no opportunity to
pre-test for barriers when writing the superblock.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:34 -08:00
|
|
|
|
|
|
|
|
|
2016-03-29 14:00:19 -07:00
|
|
|
|
2005-06-27 22:29:34 -07:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2016-03-29 14:00:19 -07:00
|
|
|
|
|
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-31 09:44:33 +02:00
|
|
|
|
[PATCH] md: support BIO_RW_BARRIER for md/raid1
We can only accept BARRIER requests if all slaves handle
barriers, and that can, of course, change with time....
So we keep track of whether the whole array seems safe for barriers,
and also whether each individual rdev handles barriers.
We initially assumes barriers are OK.
When writing the superblock we try a barrier, and if that fails, we flag
things for no-barriers. This will usually clear the flags fairly quickly.
If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
resubmit, so introduce function "md_super_wait" which waits for requests to
finish, and retries ENOTSUPP requests without the barrier flag.
When writing the real raid1, write requests which were BIO_RW_BARRIER but
which aresn't supported need to be retried. So raid1d is enhanced to do this,
and when any bio write completes (i.e. no retry needed) we remove it from the
r1bio, so that devices needing retry are easy to find.
We should hardly ever get -ENOTSUPP errors when writing data to the raid.
It should only happen if:
1/ the device used to support BARRIER, but now doesn't. Few devices
change like this, though raid1 can!
or
2/ the array has no persistent superblock, so there was no opportunity to
pre-test for barriers when writing the superblock.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:34 -08:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2016-06-05 14:31:41 -05:00
|
|
|
|
[PATCH] md: support BIO_RW_BARRIER for md/raid1
We can only accept BARRIER requests if all slaves handle
barriers, and that can, of course, change with time....
So we keep track of whether the whole array seems safe for barriers,
and also whether each individual rdev handles barriers.
We initially assumes barriers are OK.
When writing the superblock we try a barrier, and if that fails, we flag
things for no-barriers. This will usually clear the flags fairly quickly.
If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
resubmit, so introduce function "md_super_wait" which waits for requests to
finish, and retries ENOTSUPP requests without the barrier flag.
When writing the real raid1, write requests which were BIO_RW_BARRIER but
which aresn't supported need to be retried. So raid1d is enhanced to do this,
and when any bio write completes (i.e. no retry needed) we remove it from the
r1bio, so that devices needing retry are easy to find.
We should hardly ever get -ENOTSUPP errors when writing data to the raid.
It should only happen if:
1/ the device used to support BARRIER, but now doesn't. Few devices
change like this, though raid1 can!
or
2/ the array has no persistent superblock, so there was no opportunity to
pre-test for barriers when writing the superblock.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:34 -08:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
[PATCH] md: support BIO_RW_BARRIER for md/raid1
We can only accept BARRIER requests if all slaves handle
barriers, and that can, of course, change with time....
So we keep track of whether the whole array seems safe for barriers,
and also whether each individual rdev handles barriers.
We initially assumes barriers are OK.
When writing the superblock we try a barrier, and if that fails, we flag
things for no-barriers. This will usually clear the flags fairly quickly.
If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
resubmit, so introduce function "md_super_wait" which waits for requests to
finish, and retries ENOTSUPP requests without the barrier flag.
When writing the real raid1, write requests which were BIO_RW_BARRIER but
which aresn't supported need to be retried. So raid1d is enhanced to do this,
and when any bio write completes (i.e. no retry needed) we remove it from the
r1bio, so that devices needing retry are easy to find.
We should hardly ever get -ENOTSUPP errors when writing data to the raid.
It should only happen if:
1/ the device used to support BARRIER, but now doesn't. Few devices
change like this, though raid1 can!
or
2/ the array has no persistent superblock, so there was no opportunity to
pre-test for barriers when writing the superblock.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:34 -08:00
|
|
|
|
2010-09-03 11:56:18 +02:00
|
|
|
|
2014-09-09 14:20:28 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2016-06-05 14:32:07 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-08-23 19:10:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:07 -05:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2012-05-21 09:28:32 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-05 14:31:41 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:34 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:07 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-04 16:26:20 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2008-07-11 22:02:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-05-04 16:26:20 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:20 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:30 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-09 02:35:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-05-09 02:35:37 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-18 08:49:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-06-18 08:49:23 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2009-06-18 08:49:23 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2009-06-18 08:49:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:37 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-28 02:15:49 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-28 02:15:49 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2017-05-04 16:26:20 +03:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-04 16:26:20 +03:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-18 08:48:58 +10:00
|
|
|
|
2012-08-16 16:46:12 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-09-10 17:21:28 +10:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-09-10 17:21:28 +10:00
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2013-08-19 22:26:32 -04:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2006-06-26 00:27:41 -07:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2009-11-13 17:40:48 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:35 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:24:02 -07:00
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2009-11-13 17:40:48 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2005-11-08 21:39:35 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-13 17:40:48 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:03 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-13 17:40:48 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-13 17:40:48 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
|
|
|
|
|
2011-09-10 17:21:28 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
2010-11-24 16:36:17 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-21 10:24:08 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-10-21 10:24:08 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-11 13:09:00 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-21 10:24:08 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-09-09 16:23:51 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:36 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2009-05-22 17:17:49 -04:00
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2008-03-04 14:29:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2008-03-04 14:29:31 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:53 -07:00
|
|
|
|
2006-07-10 04:44:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:07 -05:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:44 +10:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2017-08-16 17:13:45 +02:00
|
|
|
|
|
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-28 02:15:49 -07:00
|
|
|
|
2006-02-03 03:03:41 -08:00
|
|
|
|
2008-04-28 02:15:49 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-03 03:03:41 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-02-03 03:03:41 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
2005-09-09 16:23:51 -07:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:36 -07:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2016-08-19 15:34:01 -07:00
|
|
|
|
2016-01-06 14:37:13 -08:00
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
2017-08-16 17:13:45 +02:00
|
|
|
|
|
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-16 17:13:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:11 -07:00
|
|
|
|
|
|
|
|
|
2010-05-18 10:17:09 +10:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:56 +10:00
|
|
|
|
|
|
|
|
|
2015-08-13 14:31:54 -07:00
|
|
|
|
2009-08-03 10:59:56 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-13 14:31:54 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-13 14:31:54 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-13 14:31:56 -07:00
|
|
|
|
2015-12-18 15:19:16 +11:00
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-02 13:49:50 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-21 10:24:08 -07:00
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2006-02-02 14:28:04 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2009-05-26 09:40:59 +10:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-02 14:28:04 -08:00
|
|
|
|
2011-08-25 14:43:08 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2011-08-25 14:43:08 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:51 -07:00
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-12-14 12:50:06 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2015-08-13 14:31:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
2015-08-19 07:35:54 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-08 08:56:27 +08:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2012-11-08 08:56:27 +08:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2012-03-19 12:46:41 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-05-23 13:58:10 -07:00
|
|
|
|
2009-08-03 10:59:57 +10:00
|
|
|
|
|
|
|
|
|
2007-05-23 13:58:10 -07:00
|
|
|
|
2009-08-03 10:59:57 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-08 16:48:17 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-12 10:45:55 +08:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2015-10-08 21:54:09 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
2017-08-16 17:13:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 09:59:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2015-08-13 14:31:54 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-08 21:54:09 -07:00
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
2009-12-14 12:50:06 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-13 14:31:54 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2008-07-21 14:42:12 +10:00
|
|
|
|
2017-03-10 11:27:23 +08:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-24 16:36:17 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:10 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-05-05 16:16:09 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-06-07 17:51:30 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2015-09-03 23:00:35 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2015-09-03 23:00:35 -07:00
|
|
|
|
|
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
2011-06-08 15:10:08 +10:00
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2011-03-28 20:09:12 -04:00
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-21 13:19:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2011-03-17 11:11:05 +01:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2011-03-17 11:11:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
2016-01-13 16:00:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
2012-10-11 13:38:58 +11:00
|
|
|
|
|
|
|
|
|
2016-01-13 16:00:07 -08:00
|
|
|
|
2012-10-11 13:38:58 +11:00
|
|
|
|
|
|
|
|
|
2016-01-13 16:00:07 -08:00
|
|
|
|
2012-10-11 13:38:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
2016-01-13 16:00:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2016-01-13 16:00:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:47 +10:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
2005-11-08 21:39:37 -08:00
|
|
|
|
2007-03-26 21:32:14 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-13 08:53:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-23 13:58:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-25 17:00:11 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-25 17:00:11 +10:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:55 -05:00
|
|
|
|
2014-09-25 17:00:11 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-25 17:00:11 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-25 17:00:11 +10:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2009-02-06 18:02:46 +11:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:35 -08:00
|
|
|
|
2015-06-25 15:02:36 -07:00
|
|
|
|
2007-12-17 23:05:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2007-12-17 23:05:35 -07:00
|
|
|
|
2007-03-26 21:32:14 -08:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2008-08-25 19:56:12 +09:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 13:25:28 +11:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2010-11-13 11:55:17 +01:00
|
|
|
|
2009-01-09 08:31:11 +11:00
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-03-26 21:32:14 -08:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2007-03-26 21:32:14 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:56 -08:00
|
|
|
|
2007-04-04 19:08:18 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2007-04-04 19:08:18 -07:00
|
|
|
|
2008-02-06 01:39:56 -08:00
|
|
|
|
2007-04-04 19:08:18 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2011-01-14 18:43:57 +01:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2008-10-21 13:25:28 +11:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2007-04-04 19:08:18 -07:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
|
|
|
|
|
2007-04-04 19:08:18 -07:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2008-02-06 01:39:56 -08:00
|
|
|
|
|
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-13 11:55:18 +01:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: make blkdev_get/put() handle exclusive access
Over time, block layer has accumulated a set of APIs dealing with bdev
open, close, claim and release.
* blkdev_get/put() are the primary open and close functions.
* bd_claim/release() deal with exclusive open.
* open/close_bdev_exclusive() are combination of open and claim and
the other way around, respectively.
* bd_link/unlink_disk_holder() to create and remove holder/slave
symlinks.
* open_by_devnum() wraps bdget() + blkdev_get().
The interface is a bit confusing and the decoupling of open and claim
makes it impossible to properly guarantee exclusive access as
in-kernel open + claim sequence can disturb the existing exclusive
open even before the block layer knows the current open if for another
exclusive access. Reorganize the interface such that,
* blkdev_get() is extended to include exclusive access management.
@holder argument is added and, if is @FMODE_EXCL specified, it will
gain exclusive access atomically w.r.t. other exclusive accesses.
* blkdev_put() is similarly extended. It now takes @mode argument and
if @FMODE_EXCL is set, it releases an exclusive access. Also, when
the last exclusive claim is released, the holder/slave symlinks are
removed automatically.
* bd_claim/release() and close_bdev_exclusive() are no longer
necessary and either made static or removed.
* bd_link_disk_holder() remains the same but bd_unlink_disk_holder()
is no longer necessary and removed.
* open_bdev_exclusive() becomes a simple wrapper around lookup_bdev()
and blkdev_get(). It also has an unexpected extra bdev_read_only()
test which probably should be moved into blkdev_get().
* open_by_devnum() is modified to take @holder argument and pass it to
blkdev_get().
Most of bdev open/close operations are unified into blkdev_get/put()
and most exclusive accesses are tested atomically at the open time (as
it should). This cleans up code and removes some, both valid and
invalid, but unnecessary all the same, corner cases.
open_bdev_exclusive() and open_by_devnum() can use further cleanup -
rename to blkdev_get_by_path() and blkdev_get_by_devt() and drop
special features. Well, let's leave them for another day.
Most conversions are straight-forward. drbd conversion is a bit more
involved as there was some reordering, but the logic should stay the
same.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Neil Brown <neilb@suse.de>
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Philipp Reisner <philipp.reisner@linbit.com>
Cc: Peter Osterlund <petero2@telia.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <joel.becker@oracle.com>
Cc: Alex Elder <aelder@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: dm-devel@redhat.com
Cc: drbd-dev@lists.linbit.com
Cc: Leo Chen <leochen@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Cc: Joern Engel <joern@logfs.org>
Cc: reiserfs-devel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
2010-11-13 11:55:17 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2012-05-22 13:54:30 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-04 14:29:31 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-25 17:43:47 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-25 17:43:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2017-07-25 15:18:13 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-07 17:51:30 -05:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-10 11:49:12 +08:00
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2015-10-12 17:21:30 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-04-24 11:42:40 +10:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2013-04-24 11:42:40 +10:00
|
|
|
|
|
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
2016-05-02 11:33:09 -04:00
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-05-03 22:22:13 -04:00
|
|
|
|
2015-10-12 17:21:30 +08:00
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
|
|
|
|
|
2015-10-12 17:21:30 +08:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-02 11:33:09 -04:00
|
|
|
|
2010-08-16 18:09:31 +10:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2010-08-16 18:09:31 +10:00
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2010-08-16 18:09:31 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2010-08-30 17:33:33 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2012-03-19 12:46:41 +11:00
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-16 18:09:31 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2006-08-27 01:23:49 -07:00
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2010-08-16 18:09:31 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-27 01:23:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2006-08-27 01:23:49 -07:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
2010-05-18 09:28:43 +10:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
2010-05-18 09:28:43 +10:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
2010-05-18 09:28:43 +10:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-18 09:44:08 -08:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
2007-07-17 04:06:13 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:57 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
|
|
|
|
|
2011-10-18 12:16:48 +11:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2005-06-21 17:17:28 -07:00
|
|
|
|
2016-05-02 11:33:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:26 -07:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-06 14:37:14 -08:00
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
2016-01-06 14:37:14 -08:00
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-06 14:37:14 -08:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
2016-01-06 14:37:14 -08:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
2016-06-02 23:32:05 -04:00
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-23 18:34:54 +01:00
|
|
|
|
2006-01-06 00:20:41 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
2008-02-06 01:39:57 -08:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2016-10-21 16:27:08 +02:00
|
|
|
|
|
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2011-12-08 16:22:48 +11:00
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2006-06-26 00:28:01 -07:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
2009-04-14 12:01:57 +10:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-25 14:42:51 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2016-07-28 09:06:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2015-10-12 17:21:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-04 16:46:03 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-11-04 16:46:03 +11:00
|
|
|
|
|
|
|
|
|
2015-10-12 17:21:27 +08:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2006-06-26 00:28:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2016-10-21 16:27:08 +02:00
|
|
|
|
2011-08-30 16:20:17 +10:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 12:01:57 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:01 -07:00
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:24:25 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
|
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-09 11:42:54 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
|
|
|
|
|
2009-04-14 12:01:57 +10:00
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
2015-12-18 15:19:16 +11:00
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-02 11:57:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-18 12:13:47 +11:00
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2015-12-18 15:19:16 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:31 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2006-01-06 00:20:59 -08:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2008-06-28 08:31:29 +10:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
2008-03-04 14:29:33 -08:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
2008-07-12 10:37:50 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2008-07-12 10:37:50 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2013-02-21 14:33:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-10-13 11:55:11 +11:00
|
|
|
|
2008-06-28 08:31:46 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2014-09-29 15:33:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
2014-09-29 15:33:20 +10:00
|
|
|
|
2008-02-06 01:39:58 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-01-31 12:10:09 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-29 15:33:20 +10:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2009-12-12 21:17:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2009-12-12 21:17:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2009-12-12 21:17:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:52 -08:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
2006-01-06 00:20:56 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2006-01-06 00:21:06 -08:00
|
|
|
|
2009-12-12 21:17:12 -07:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2008-03-04 14:29:33 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:19 -07:00
|
|
|
|
|
|
|
|
|
2008-03-04 14:29:33 -08:00
|
|
|
|
2008-02-06 01:39:55 -08:00
|
|
|
|
2008-03-04 14:29:33 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:28 -07:00
|
|
|
|
2008-02-06 01:39:55 -08:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
2010-01-19 02:58:23 +01:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2010-06-01 19:37:26 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2010-06-01 19:37:26 +10:00
|
|
|
|
2016-06-17 17:33:10 +02:00
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:26 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2010-06-01 19:37:26 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:32 -08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-17 23:05:35 -07:00
|
|
|
|
2005-11-08 21:39:24 -08:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2007-07-17 04:06:11 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:47 +10:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:54:30 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2010-04-14 17:02:09 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2009-02-06 18:02:46 +11:00
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-23 13:58:10 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:55 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2009-12-14 12:49:55 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
|
|
|
|
|
2008-09-24 22:48:19 -07:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:55 +11:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-05 15:54:13 +10:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2010-05-02 10:04:16 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2010-05-02 10:04:16 -07:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2014-05-28 13:39:21 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2010-05-02 10:04:16 -07:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2010-05-02 10:04:16 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2010-05-02 10:04:16 -07:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2010-03-08 16:02:42 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-23 12:11:01 +02:00
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:55 +10:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2009-08-03 10:59:55 +10:00
|
|
|
|
2010-06-15 09:36:03 +01:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2010-03-08 16:02:44 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:15 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2012-05-22 13:55:29 +10:00
|
|
|
|
2014-01-14 15:17:03 +11:00
|
|
|
|
|
|
|
|
|
2010-04-14 17:17:39 +10:00
|
|
|
|
2010-05-01 18:14:57 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2009-06-18 08:47:55 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:47:42 +10:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2005-11-08 21:39:45 -08:00
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2009-06-18 08:47:55 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:47:42 +10:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2009-03-31 14:56:41 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2009-03-31 15:24:32 +11:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-11 15:52:21 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-25 21:00:53 +01:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:28:01 -07:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2016-10-24 12:47:28 +02:00
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-10-25 17:07:08 +02:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2016-06-30 10:47:09 +02:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2015-06-12 19:46:44 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-31 10:04:55 +10:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2012-07-31 10:04:55 +10:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2009-05-07 12:50:57 +10:00
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2011-12-08 15:49:12 +11:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
2015-06-25 17:06:40 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
2015-06-25 17:06:40 +10:00
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2017-07-28 15:49:25 +02:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 18:01:06 -08:00
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2016-06-12 17:18:00 +08:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2012-10-30 00:18:08 +09:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-10-13 11:55:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:57 -08:00
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
2006-12-22 01:11:41 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:34 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
|
|
|
|
|
2009-05-26 09:41:17 +10:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:09 -08:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2015-07-06 12:26:57 +10:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-26 09:41:17 +10:00
|
|
|
|
|
|
|
|
|
2015-05-28 17:53:29 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-12 19:51:27 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2015-06-12 19:51:27 +10:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
2015-12-21 11:01:21 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2015-05-28 17:53:29 +10:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2015-05-28 17:53:29 +10:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2015-12-21 11:01:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:43 +10:00
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
2006-01-06 00:20:41 -08:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
2006-05-20 14:59:57 -07:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
2015-05-28 17:53:29 +10:00
|
|
|
|
2005-11-08 21:39:44 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:19:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:46 -08:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
2012-10-11 14:17:59 +11:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 23:30:54 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2007-10-16 23:30:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
2009-03-31 15:24:32 +11:00
|
|
|
|
|
|
|
|
|
2008-03-25 22:24:09 +01:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2008-03-25 22:24:09 +01:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:28:33 +10:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
2014-09-30 08:53:05 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2015-03-23 17:36:38 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-01 16:15:16 +09:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2009-08-13 10:41:50 +10:00
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-06-16 17:01:42 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
2016-05-02 11:33:13 -04:00
|
|
|
|
2017-04-10 14:15:55 +08:00
|
|
|
|
|
|
|
|
|
2016-05-02 11:33:13 -04:00
|
|
|
|
2017-04-10 14:15:55 +08:00
|
|
|
|
2016-05-02 11:33:13 -04:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-16 13:58:38 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:03 +01:00
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
2017-03-09 10:00:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:03 +01:00
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
2017-03-09 10:00:03 +01:00
|
|
|
|
|
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:59 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
2006-01-06 00:20:47 -08:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2006-06-26 00:28:00 -07:00
|
|
|
|
2006-01-06 00:20:50 -08:00
|
|
|
|
2006-01-06 00:21:16 -08:00
|
|
|
|
2006-06-26 00:27:37 -07:00
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2007-05-09 02:35:38 -07:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
2017-03-09 10:00:00 +01:00
|
|
|
|
2005-11-08 21:39:40 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2006-03-27 01:18:14 -08:00
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:49 -07:00
|
|
|
|
2007-10-16 23:30:54 -07:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:40 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:39 -08:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 15:49:46 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2011-12-08 15:49:46 +11:00
|
|
|
|
2005-11-08 21:39:39 -08:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-11-08 21:39:39 -08:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:19 -07:00
|
|
|
|
|
|
|
|
|
2011-12-08 15:49:46 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2011-12-08 15:49:46 +11:00
|
|
|
|
2005-11-08 21:39:39 -08:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-01-09 08:31:09 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-27 14:12:22 +10:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:09 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
2009-01-09 08:31:09 +11:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-19 02:58:23 +01:00
|
|
|
|
2005-11-08 21:39:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-04 00:57:25 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-04 00:57:25 -07:00
|
|
|
|
2009-12-14 12:49:55 +11:00
|
|
|
|
2009-03-04 00:57:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2017-06-05 16:05:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:20 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-17 15:54:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2006-03-27 01:18:20 -08:00
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-11 16:27:11 +01:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
|
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-20 21:15:16 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-30 10:16:53 -06:00
|
|
|
|
2008-10-21 13:25:32 +11:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2008-10-21 13:25:32 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-05-10 17:49:01 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-25 19:56:05 +09:00
|
|
|
|
|
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2011-05-10 17:49:01 +10:00
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2007-12-17 15:54:39 -04:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-10-21 13:25:21 +11:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2009-07-01 12:27:21 +10:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:15 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-04-16 15:26:42 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-08 21:18:03 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-15 10:13:47 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:26:42 -07:00
|
|
|
|
2008-02-06 01:39:53 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-05-06 14:49:54 -07:00
|
|
|
|
2017-04-13 08:53:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-02-14 23:29:00 +08:00
|
|
|
|
2017-06-18 14:38:57 +10:00
|
|
|
|
2017-02-14 23:29:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
2017-07-08 12:50:18 -07:00
|
|
|
|
2017-06-21 09:12:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-26 18:31:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:38 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2007-02-28 20:11:35 -08:00
|
|
|
|
|
|
|
|
|
2005-08-26 18:34:16 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:15 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-30 12:08:50 +11:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
2017-01-23 17:12:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2008-03-26 00:07:03 +01:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2012-05-22 13:55:08 +10:00
|
|
|
|
2014-06-06 12:43:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-06-06 12:43:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:16 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
2015-03-13 11:51:18 +11:00
|
|
|
|
|
|
|
|
|
2015-06-25 17:01:40 +10:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2016-09-30 09:45:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-02 15:56:50 +01:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2007-03-26 21:32:14 -08:00
|
|
|
|
2005-11-08 21:39:42 -08:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2015-07-17 11:57:30 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:43 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-03-29 11:10:42 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-07 17:49:36 -05:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-07 17:49:36 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-29 11:10:42 +11:00
|
|
|
|
|
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
2010-03-29 11:10:42 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-13 08:53:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-11 22:02:21 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-11 22:02:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:13 -07:00
|
|
|
|
2017-04-13 08:53:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:13 -07:00
|
|
|
|
2017-04-13 08:53:48 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:13 -07:00
|
|
|
|
2008-07-11 22:02:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2008-07-11 22:02:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-07-11 22:02:21 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 09:28:43 +10:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:17:59 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
2015-06-25 17:01:40 +10:00
|
|
|
|
2016-08-12 13:42:38 +08:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-12 13:42:38 +08:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
2013-05-09 09:48:30 +10:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-21 10:29:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:42 +10:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
|
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2013-11-14 17:54:51 +11:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2010-03-29 12:07:53 +11:00
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
|
|
|
|
|
2017-03-14 09:40:20 +08:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 10:47:48 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2017-03-14 09:40:20 +08:00
|
|
|
|
2014-12-15 12:56:57 +11:00
|
|
|
|
2015-07-22 10:20:07 +10:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
2015-06-25 17:01:40 +10:00
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 12:08:16 +11:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2012-11-19 10:47:48 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:27 +10:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2015-09-24 14:00:51 +10:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
|
|
|
|
|
2015-09-24 14:00:51 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
2014-09-09 14:00:15 +10:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2016-08-12 13:42:37 +08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2014-10-29 08:49:50 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-29 08:49:50 +11:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-08-10 12:50:52 +10:00
|
|
|
|
2014-09-09 14:00:15 +10:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2016-08-12 13:42:37 +08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2010-08-07 21:41:19 +10:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2014-10-29 08:49:50 +11:00
|
|
|
|
2013-11-14 15:16:17 +11:00
|
|
|
|
|
|
|
|
|
2013-08-27 16:44:13 +10:00
|
|
|
|
|
|
|
|
|
2010-08-07 21:41:19 +10:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2012-11-19 10:47:48 +11:00
|
|
|
|
2017-02-02 15:56:50 +01:00
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2006-12-10 02:20:44 -08:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
|
|
|
|
|
2009-05-07 12:51:06 +10:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
2010-08-07 21:41:19 +10:00
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
2006-12-10 02:20:44 -08:00
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
|
|
|
|
|
2010-08-07 21:41:19 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: Set/get state of array via sysfs
This allows the state of an md/array to be directly controlled via sysfs and
adds the ability to stop and array without tearing it down.
Array states/settings:
clear
No devices, no size, no level
Equivalent to STOP_ARRAY ioctl
inactive
May have some settings, but array is not active
all IO results in error
When written, doesn't tear down array, but just stops it
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
write requests fail
read-auto
like readonly, but behaves like 'clean' on a write request.
clean - no pending writes, but otherwise active.
When written to inactive array, starts without resync
If a write request arrives then
if metadata is known, mark 'dirty' and switch to 'active'.
if not known, block and switch to write-pending
If written to an active array that has pending writes, then fails.
active
fully active: IO and resync can be happening.
When written to inactive array, starts with resync
write-pending (not supported yet)
clean, but writes are blocked waiting for 'active' to be written.
active-idle
like active, but no writes have been seen for a while (100msec).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:27:58 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
2006-02-02 14:28:05 -08:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2006-02-02 14:28:05 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-03-29 11:37:13 +11:00
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
2010-03-29 13:23:10 +11:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2010-08-07 21:41:19 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-10 02:20:50 -08:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:26:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2012-07-19 15:59:18 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-03 01:15:59 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:18:07 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:17 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2008-02-06 01:39:53 -08:00
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-12-10 02:20:50 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-09-23 18:06:41 +10:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2016-08-11 17:14:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2006-02-03 03:03:40 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2014-07-02 11:35:06 +10:00
|
|
|
|
2014-11-26 12:22:03 -06:00
|
|
|
|
|
|
|
|
|
2009-09-23 18:06:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2015-07-25 16:36:50 +02:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2015-07-25 16:36:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
2015-04-14 10:43:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-12 16:59:50 -07:00
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-23 18:06:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 16:36:28 +11:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
|
|
|
|
|
2011-01-12 09:03:35 +11:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
2011-01-12 09:03:35 +11:00
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2011-01-12 09:03:35 +11:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2005-06-21 17:17:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-11 14:26:20 +10:00
|
|
|
|
2012-07-03 15:59:06 +10:00
|
|
|
|
2011-05-11 14:26:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-17 14:24:09 +11:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-13 14:31:55 -07:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
|
|
|
|
|
2016-08-12 13:42:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:45:22 -05:00
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2016-11-18 16:16:11 +11:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2009-06-18 08:48:58 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-28 10:27:26 -05:00
|
|
|
|
|
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-28 10:27:26 -05:00
|
|
|
|
2015-12-21 10:51:00 +11:00
|
|
|
|
2015-04-14 10:44:44 -05:00
|
|
|
|
|
|
|
|
|
2015-04-14 10:43:24 -05:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-11-04 16:46:03 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-11-08 14:39:12 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-18 08:48:58 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-06 00:44:04 -07:00
|
|
|
|
2006-01-06 00:20:55 -08:00
|
|
|
|
|
|
|
|
|
2015-09-28 19:21:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-11-04 16:46:03 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-08-08 15:40:24 +10:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-04-09 12:25:40 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:35 +10:00
|
|
|
|
2014-06-06 12:43:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:35 +10:00
|
|
|
|
2015-02-25 11:44:11 +11:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:35 +10:00
|
|
|
|
2006-06-26 00:27:43 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2006-06-26 00:27:43 -07:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2006-06-26 00:27:43 -07:00
|
|
|
|
|
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 02:35:34 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-22 01:11:41 -08:00
|
|
|
|
2009-12-30 12:08:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-16 22:14:57 -08:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2017-03-01 07:31:28 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2005-11-28 13:44:12 -08:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
2009-06-18 08:45:27 +10:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2006-03-27 01:18:11 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:59:03 +11:00
|
|
|
|
2009-03-31 15:00:31 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:59:03 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
2017-03-01 16:42:40 +08:00
|
|
|
|
2016-05-02 11:33:13 -04:00
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:23 +10:00
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
2014-05-28 13:39:21 +10:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:27 +10:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-10-28 10:38:30 -07:00
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
2017-02-24 11:15:23 +08:00
|
|
|
|
2017-03-01 16:42:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-24 11:15:23 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2014-05-28 13:39:21 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2010-04-14 17:02:09 +10:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:13 -08:00
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2011-01-31 11:57:42 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-11 09:41:10 +08:00
|
|
|
|
2009-06-18 08:45:01 +10:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 08:47:55 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-18 08:47:42 +10:00
|
|
|
|
|
|
|
|
|
2009-06-18 08:47:55 +10:00
|
|
|
|
2009-06-18 08:47:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2008-07-11 22:02:22 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:54 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-06-06 12:43:49 -05:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:07 +10:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
2014-06-06 12:43:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:35 +10:00
|
|
|
|
2015-02-25 11:44:11 +11:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2015-12-21 10:51:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-14 12:49:52 +11:00
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2014-06-07 01:44:51 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-25 18:57:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-29 10:51:42 +11:00
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-15 16:58:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
2014-01-15 16:58:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:31:15 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2010-05-12 08:25:37 +10:00
|
|
|
|
2017-04-06 11:16:33 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-15 16:58:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:26 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:31:15 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2014-12-15 12:57:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 13:37:33 +11:00
|
|
|
|
|
|
|
|
|
2012-12-11 13:35:54 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-02 08:38:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:18 -08:00
|
|
|
|
2013-04-02 08:38:55 +02:00
|
|
|
|
2013-08-27 16:44:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-09 14:00:15 +10:00
|
|
|
|
2013-08-27 16:44:13 +10:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2013-08-27 16:44:13 +10:00
|
|
|
|
2017-04-06 11:16:33 +08:00
|
|
|
|
2016-08-12 13:42:37 +08:00
|
|
|
|
2017-04-06 11:16:33 +08:00
|
|
|
|
2013-08-27 16:44:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2006-12-22 01:11:41 -08:00
|
|
|
|
2008-02-06 01:39:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
2016-03-21 19:19:30 +08:00
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-12 08:25:37 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:36:28 +10:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
2013-02-28 11:59:03 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2013-02-28 11:59:03 +11:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2013-11-14 17:54:51 +11:00
|
|
|
|
2013-02-28 11:59:03 +11:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-10-29 18:51:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2012-12-11 13:39:21 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:46:41 +10:00
|
|
|
|
2017-04-06 11:16:33 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-14 12:50:05 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:31:15 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-22 13:55:32 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-10 12:50:52 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-08-12 13:42:37 +08:00
|
|
|
|
|
|
|
|
|
2016-12-05 16:40:50 +11:00
|
|
|
|
|
|
|
|
|
2016-08-12 13:42:37 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2009-08-10 12:50:52 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-05 16:40:50 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-05 21:52:57 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-03 23:33:23 +02:00
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 17:01:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-03-02 10:31:15 -05:00
|
|
|
|
|
|
|
|
|
2009-05-26 12:57:36 +10:00
|
|
|
|
2009-12-14 12:50:05 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
2011-02-24 17:26:41 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-10-19 21:23:47 -07:00
|
|
|
|
2005-09-09 16:23:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-15 00:09:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-21 10:29:18 -08:00
|
|
|
|
2005-11-15 00:09:12 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-14 09:13:53 +11:00
|
|
|
|
2016-11-21 10:29:18 -08:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:13:53 +11:00
|
|
|
|
2012-10-11 13:34:00 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:23:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-11 13:34:00 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
2009-09-23 18:09:45 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-03 15:56:52 +10:00
|
|
|
|
2005-09-09 16:23:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:48:23 +11:00
|
|
|
|
2009-03-31 14:39:39 +11:00
|
|
|
|
|
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
2011-09-21 15:30:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:56 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
|
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-26 11:49:55 +10:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
2015-12-28 10:46:38 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:08 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-02 17:12:58 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-21 09:28:33 +10:00
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-02 17:12:58 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-27 01:18:04 -08:00
|
|
|
|
2006-03-27 01:18:09 -08:00
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-30 22:57:33 -03:00
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:16 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-07 12:49:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-10 04:44:16 -07:00
|
|
|
|
2015-07-02 17:12:58 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 20:48:39 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
2008-03-10 11:43:47 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:23:45 -07:00
|
|
|
|
|
|
|
|
|
2015-10-12 16:59:50 -07:00
|
|
|
|
|
|
|
|
|
2005-11-08 21:39:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
2005-09-09 16:24:00 -07:00
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-12-15 12:56:59 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 17:05:22 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-09 16:24:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 16:24:00 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-11-08 21:39:41 -08:00
|
|
|
|
2015-07-02 17:12:58 +10:00
|
|
|
|
2005-11-08 21:39:41 -08:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:40 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:58 +11:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 12:49:37 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 20:48:39 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2011-07-12 20:48:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-09 14:33:51 +10:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
2011-07-12 20:48:39 +02:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
2014-04-09 14:33:51 +10:00
|
|
|
|
2014-12-03 16:07:59 +11:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-12 20:48:39 +02:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-12 00:55:33 -08:00
|
|
|
|
2006-10-17 00:09:38 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-29 19:52:45 +03:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-11 16:49:58 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:20:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-13 12:32:55 +10:00
|
|
|
|
|
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2015-08-13 12:32:55 +10:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2015-08-13 12:32:55 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2015-08-13 12:32:55 +10:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-04 22:17:28 -04:00
|
|
|
|
|
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2016-09-04 22:17:28 -04:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-30 00:42:49 -05:00
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-29 10:20:02 -05:00
|
|
|
|
|
|
|
|
|
2014-03-29 10:01:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 14:23:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-17 04:06:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-18 01:11:01 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-21 17:05:25 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort
the recovery and restart it.
For RAID6 (and multi-drive RAID1) it may not be best to restart at the
beginning: when multiple failures can be tolerated, the recovery may be
able to continue and re-doing all that has already been done doesn't make
sense.
We already have the infrastructure to record where a recovery is up to
and restart from there, but it is not being used properly.
This is because:
- We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR,
which causes the recovery not be be checkpointed.
- We remove spares and then re-added them which loses important state
information.
The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't
needed. If there is an error, the relevant drive will be marked as
Faulty, and that is enough to ensure correct handling of the error. So we
first remove MD_RECOVERY_ERR, changing some of the uses of it to
MD_RECOVERY_INTR.
Then we cause the attempt to remove a non-faulty device from an array to
fail (unless recovery is impossible as the array is too degraded). Then
when remove_and_add_spares attempts to remove the devices on which
recovery can continue, it will fail, they will remain in place, and
recovery will continue on them as desired.
Issue: If we are halfway through rebuilding a spare and another drive
fails, and a new spare is immediately available, do we want to:
1/ complete the current rebuild, then go back and rebuild the new spare or
2/ restart the rebuild from the start and rebuild both devices in
parallel.
Both options can be argued for. The code currently takes option 2 as
a/ this requires least code change
b/ this results in a minimally-degraded array in minimal time.
Cc: "Eivind Sarto" <ivan@kasenna.com>
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>
2008-05-23 13:04:39 -07:00
|
|
|
|
2012-11-19 19:57:34 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:26 -07:00
|
|
|
|
|
|
|
|
|
2017-06-05 16:49:39 +10:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2017-06-05 16:49:39 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2017-06-05 16:49:39 +10:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-04 14:29:32 -08:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
|
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
2017-08-08 16:56:36 +10:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2005-06-21 17:17:26 -07:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:26 -07:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
2005-06-21 17:17:26 -07:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
2008-06-28 08:31:36 +10:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-05-23 13:04:36 -07:00
|
|
|
|
2017-10-05 16:23:16 +11:00
|
|
|
|
|
|
|
|
|
2017-06-05 16:49:39 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md/raid5: use md_write_start to count stripes, not bios
We use md_write_start() to increase the count of pending writes, and
md_write_end() to decrement the count. We currently count bios
submitted to md/raid5. Change it count stripe_heads that a WRITE bio
has been attached to.
So now, raid5_make_request() calls md_write_start() and then
md_write_end() to keep the count elevated during the setup of the
request.
add_stripe_bio() calls md_write_start() for each stripe_head, and the
completion routines always call md_write_end(), instead of only
calling it when raid5_dec_bi_active_stripes() returns 0.
make_discard_request also calls md_write_start/end().
The parallel between md_write_{start,end} and use of bi_phys_segments
can be seen in that:
Whenever we set bi_phys_segments to 1, we now call md_write_start.
Whenever we increment it on non-read requests with
raid5_inc_bi_active_stripes(), we now call md_write_start().
Whenever we decrement bi_phys_segments on non-read requsts with
raid5_dec_bi_active_stripes(), we now call md_write_end().
This reduces our dependence on keeping a per-bio count of active
stripes in bi_phys_segments.
md_write_inc() is added which parallels md_write_start(), but requires
that a write has already been started, and is certain never to sleep.
This can be used inside a spinlocked region when adding to a write
request.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:12 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
md/raid5: use md_write_start to count stripes, not bios
We use md_write_start() to increase the count of pending writes, and
md_write_end() to decrement the count. We currently count bios
submitted to md/raid5. Change it count stripe_heads that a WRITE bio
has been attached to.
So now, raid5_make_request() calls md_write_start() and then
md_write_end() to keep the count elevated during the setup of the
request.
add_stripe_bio() calls md_write_start() for each stripe_head, and the
completion routines always call md_write_end(), instead of only
calling it when raid5_dec_bi_active_stripes() returns 0.
make_discard_request also calls md_write_start/end().
The parallel between md_write_{start,end} and use of bi_phys_segments
can be seen in that:
Whenever we set bi_phys_segments to 1, we now call md_write_start.
Whenever we increment it on non-read requests with
raid5_inc_bi_active_stripes(), we now call md_write_start().
Whenever we decrement bi_phys_segments on non-read requsts with
raid5_dec_bi_active_stripes(), we now call md_write_end().
This reduces our dependence on keeping a per-bio count of active
stripes in bi_phys_segments.
md_write_inc() is added which parallels md_write_start(), but requires
that a write has already been started, and is certain never to sleep.
This can be used inside a spinlocked region when adding to a write
request.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:12 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-08 11:56:55 +02:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
|
|
|
|
|
2017-05-08 11:56:55 +02:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
2017-05-08 11:56:55 +02:00
|
|
|
|
2008-06-28 08:31:27 +10:00
|
|
|
|
2017-05-08 11:56:55 +02:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2017-05-08 11:56:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2007-01-26 00:57:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
2012-10-11 13:34:00 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-11 13:34:00 +11:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-08-07 09:37:41 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
md:Add blk_plug in sync_thread.
Add blk_plug in sync_thread will increase the performance of sync.
Because sync_thread did not blk_plug,so when raid sync, the bio merge
not well.
Testing environment:
SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI
Controller.
OS:Linux xxx 3.5.0-rc2+ #340 SMP Tue Jun 12 09:00:25 CST 2012
x86_64 x86_64 x86_64 GNU/Linux.
RAID5: four ST31000524NS disk.
Without blk_plug:recovery speed about 63M/Sec;
Add blk_plug:recovery speed about 120M/Sec.
Using blktrace:
blktrace -d /dev/sdb -w 60 -o -|blkparse -i -
without blk_plug:
Total (8,16):
Reads Queued: 309811, 1239MiB Writes Queued: 0, 0KiB
Read Dispatches: 283583, 1189MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 273351, 1149MiB Writes Completed: 0, 0KiB
Read Merges: 23533, 94132KiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 0
add blk_plug:
Total (8,16):
Reads Queued: 428697, 1714MiB Writes Queued: 0, 0KiB
Read Dispatches: 3954, 1714MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 3956, 1715MiB Writes Completed: 0, 0KiB
Read Merges: 424743, 1698MiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 3384
The ratio of merge will be markedly increased.
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2012-07-03 12:12:26 +10:00
|
|
|
|
2016-05-02 11:33:08 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-28 13:39:23 +10:00
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2014-05-28 13:39:23 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-05-02 11:33:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 23:32:04 -04:00
|
|
|
|
2016-05-02 11:33:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:57 -07:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
2006-10-03 01:15:57 -07:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:57 -07:00
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
|
|
|
|
|
2006-10-03 01:15:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-25 01:23:59 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-16 14:26:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-30 15:25:23 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-06 01:39:58 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-05-23 13:04:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-19 11:49:54 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
2005-10-26 01:58:58 -07:00
|
|
|
|
2016-08-16 14:26:08 +02:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-16 14:26:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-09-19 11:49:54 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-11 14:17:59 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2008-06-28 08:31:24 +10:00
|
|
|
|
2006-03-27 01:18:09 -08:00
|
|
|
|
2012-05-21 09:28:33 +10:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2009-12-12 21:17:06 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-12 21:17:06 -07:00
|
|
|
|
2014-07-02 12:04:14 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
|
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md:Add blk_plug in sync_thread.
Add blk_plug in sync_thread will increase the performance of sync.
Because sync_thread did not blk_plug,so when raid sync, the bio merge
not well.
Testing environment:
SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI
Controller.
OS:Linux xxx 3.5.0-rc2+ #340 SMP Tue Jun 12 09:00:25 CST 2012
x86_64 x86_64 x86_64 GNU/Linux.
RAID5: four ST31000524NS disk.
Without blk_plug:recovery speed about 63M/Sec;
Add blk_plug:recovery speed about 120M/Sec.
Using blktrace:
blktrace -d /dev/sdb -w 60 -o -|blkparse -i -
without blk_plug:
Total (8,16):
Reads Queued: 309811, 1239MiB Writes Queued: 0, 0KiB
Read Dispatches: 283583, 1189MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 273351, 1149MiB Writes Completed: 0, 0KiB
Read Merges: 23533, 94132KiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 0
add blk_plug:
Total (8,16):
Reads Queued: 428697, 1714MiB Writes Queued: 0, 0KiB
Read Dispatches: 3954, 1714MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 3956, 1715MiB Writes Completed: 0, 0KiB
Read Merges: 424743, 1698MiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 3384
The ratio of merge will be markedly increased.
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2012-07-03 12:12:26 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-05-26 12:57:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
2009-05-26 12:57:21 +10:00
|
|
|
|
2015-07-17 12:06:02 +10:00
|
|
|
|
|
|
|
|
|
2009-05-26 12:57:21 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:34 +11:00
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-31 11:59:10 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
2009-03-31 14:33:13 +11:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
|
|
|
|
|
2009-07-01 13:15:35 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
|
|
|
|
|
2009-07-01 13:15:35 +10:00
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
|
|
|
|
|
2009-04-14 16:28:34 +10:00
|
|
|
|
2015-02-19 16:04:40 +11:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort
the recovery and restart it.
For RAID6 (and multi-drive RAID1) it may not be best to restart at the
beginning: when multiple failures can be tolerated, the recovery may be
able to continue and re-doing all that has already been done doesn't make
sense.
We already have the infrastructure to record where a recovery is up to
and restart from there, but it is not being used properly.
This is because:
- We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR,
which causes the recovery not be be checkpointed.
- We remove spares and then re-added them which loses important state
information.
The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't
needed. If there is an error, the relevant drive will be marked as
Faulty, and that is enough to ensure correct handling of the error. So we
first remove MD_RECOVERY_ERR, changing some of the uses of it to
MD_RECOVERY_INTR.
Then we cause the attempt to remove a non-faulty device from an array to
fail (unless recovery is impossible as the array is too degraded). Then
when remove_and_add_spares attempts to remove the devices on which
recovery can continue, it will fail, they will remain in place, and
recovery will continue on them as desired.
Issue: If we are halfway through rebuilding a spare and another drive
fails, and a new spare is immediately available, do we want to:
1/ complete the current rebuild, then go back and rebuild the new spare or
2/ restart the rebuild from the start and rebuild both devices in
parallel.
Both options can be argued for. The code currently takes option 2 as
a/ this requires least code change
b/ this results in a minimally-degraded array in minimal time.
Cc: "Eivind Sarto" <ivan@kasenna.com>
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>
2008-05-23 13:04:39 -07:00
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:39:24 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-24 13:27:08 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:16 -07:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
2011-07-28 11:39:24 +10:00
|
|
|
|
[PATCH] md: make /proc/mdstat pollable
With this patch it is possible to poll /proc/mdstat to detect arrays appearing
or disappearing, to detect failures, recovery starting, recovery completing,
and devices being added and removed.
It is similar to the poll-ability of /proc/mounts, though different in that:
We always report that the file is readable (because face it, it is, even if
only for EOF).
We report POLLPRI when there is a change so that select() can detect
it as an exceptional event. Not only are these exceptional events, but
that is the mechanism that the current 'mdadm' uses to watch for events
(It also polls after a timeout).
(We also report POLLERR like /proc/mounts).
Finally, we only reset the per-file event counter when the start of the file
is read, rather than when poll() returns an event. This is more robust as it
means that an fd will continue to report activity to poll/select until the
program clearly responds to that activity.
md_new_event takes an 'mddev' which isn't currently used, but it will be soon.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 00:20:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-19 12:02:01 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-07 09:37:41 -04:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:21:36 -08:00
|
|
|
|
2015-02-19 16:55:00 +11:00
|
|
|
|
2005-11-18 01:11:01 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-02-19 16:55:00 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md:Add blk_plug in sync_thread.
Add blk_plug in sync_thread will increase the performance of sync.
Because sync_thread did not blk_plug,so when raid sync, the bio merge
not well.
Testing environment:
SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI
Controller.
OS:Linux xxx 3.5.0-rc2+ #340 SMP Tue Jun 12 09:00:25 CST 2012
x86_64 x86_64 x86_64 GNU/Linux.
RAID5: four ST31000524NS disk.
Without blk_plug:recovery speed about 63M/Sec;
Add blk_plug:recovery speed about 120M/Sec.
Using blktrace:
blktrace -d /dev/sdb -w 60 -o -|blkparse -i -
without blk_plug:
Total (8,16):
Reads Queued: 309811, 1239MiB Writes Queued: 0, 0KiB
Read Dispatches: 283583, 1189MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 273351, 1149MiB Writes Completed: 0, 0KiB
Read Merges: 23533, 94132KiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 0
add blk_plug:
Total (8,16):
Reads Queued: 428697, 1714MiB Writes Queued: 0, 0KiB
Read Dispatches: 3954, 1714MiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 3956, 1715MiB Writes Completed: 0, 0KiB
Read Merges: 424743, 1698MiB Write Merges: 0, 0KiB
IO unplugs: 0 Timer unplugs: 3384
The ratio of merge will be markedly increased.
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2012-07-03 12:12:26 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-07-24 13:27:08 +10:00
|
|
|
|
|
|
|
|
|
md: be careful not lot leak internal curr_resync value into metadata. -- (all)
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2016-10-28 15:59:41 +11:00
|
|
|
|
2015-07-24 13:27:08 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-19 16:04:40 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort
the recovery and restart it.
For RAID6 (and multi-drive RAID1) it may not be best to restart at the
beginning: when multiple failures can be tolerated, the recovery may be
able to continue and re-doing all that has already been done doesn't make
sense.
We already have the infrastructure to record where a recovery is up to
and restart from there, but it is not being used properly.
This is because:
- We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR,
which causes the recovery not be be checkpointed.
- We remove spares and then re-added them which loses important state
information.
The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't
needed. If there is an error, the relevant drive will be marked as
Faulty, and that is enough to ensure correct handling of the error. So we
first remove MD_RECOVERY_ERR, changing some of the uses of it to
MD_RECOVERY_INTR.
Then we cause the attempt to remove a non-faulty device from an array to
fail (unless recovery is impossible as the array is too degraded). Then
when remove_and_add_spares attempts to remove the devices on which
recovery can continue, it will fail, they will remain in place, and
recovery will continue on them as desired.
Issue: If we are halfway through rebuilding a spare and another drive
fails, and a new spare is immediately available, do we want to:
1/ complete the current rebuild, then go back and rebuild the new spare or
2/ restart the rebuild from the start and rebuild both devices in
parallel.
Both options can be argued for. The code currently takes option 2 as
a/ this requires least code change
b/ this results in a minimally-degraded array in minimal time.
Cc: "Eivind Sarto" <ivan@kasenna.com>
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>
2008-05-23 13:04:39 -07:00
|
|
|
|
md: be careful not lot leak internal curr_resync value into metadata. -- (all)
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2016-10-28 15:59:41 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2012-11-19 19:57:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-12 21:17:06 -07:00
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2010-06-16 17:01:25 +10:00
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-12 21:17:06 -07:00
|
|
|
|
2006-06-26 00:27:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-07 12:01:51 +11:00
|
|
|
|
2016-06-02 23:32:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2015-09-30 13:20:35 -05:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2009-12-14 12:49:48 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-02 17:12:58 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-06 01:39:52 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-27 01:18:10 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2012-01-09 00:46:41 +11:00
|
|
|
|
2016-06-02 16:19:53 +10:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2016-06-02 16:19:53 +10:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2016-06-02 16:19:53 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
|
|
|
|
|
2016-06-02 16:19:53 +10:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2011-12-23 10:17:51 +11:00
|
|
|
|
2011-07-27 11:00:36 +10:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2012-01-09 00:46:41 +11:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
|
|
|
|
|
2016-06-02 16:19:53 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-07 16:24:26 -06:00
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2015-09-28 10:27:26 -05:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:39 +11:00
|
|
|
|
2015-09-28 10:27:26 -05:00
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
|
|
|
|
|
2011-12-23 10:17:53 +11:00
|
|
|
|
|
|
|
|
|
2015-10-08 21:54:12 -07:00
|
|
|
|
2011-12-23 10:17:53 +11:00
|
|
|
|
|
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:51:02 +11:00
|
|
|
|
|
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort
the recovery and restart it.
For RAID6 (and multi-drive RAID1) it may not be best to restart at the
beginning: when multiple failures can be tolerated, the recovery may be
able to continue and re-doing all that has already been done doesn't make
sense.
We already have the infrastructure to record where a recovery is up to
and restart from there, but it is not being used properly.
This is because:
- We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR,
which causes the recovery not be be checkpointed.
- We remove spares and then re-added them which loses important state
information.
The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't
needed. If there is an error, the relevant drive will be marked as
Faulty, and that is enough to ensure correct handling of the error. So we
first remove MD_RECOVERY_ERR, changing some of the uses of it to
MD_RECOVERY_INTR.
Then we cause the attempt to remove a non-faulty device from an array to
fail (unless recovery is impossible as the array is too degraded). Then
when remove_and_add_spares attempts to remove the devices on which
recovery can continue, it will fail, they will remain in place, and
recovery will continue on them as desired.
Issue: If we are halfway through rebuilding a spare and another drive
fails, and a new spare is immediately available, do we want to:
1/ complete the current rebuild, then go back and rebuild the new spare or
2/ restart the rebuild from the start and rebuild both devices in
parallel.
Both options can be argued for. The code currently takes option 2 as
a/ this requires least code change
b/ this results in a minimally-degraded array in minimal time.
Cc: "Eivind Sarto" <ivan@kasenna.com>
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>
2008-05-23 13:04:39 -07:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
2012-09-19 12:54:22 +10:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
|
|
|
|
|
2011-01-14 09:14:33 +11:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-30 13:20:35 -05:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort
the recovery and restart it.
For RAID6 (and multi-drive RAID1) it may not be best to restart at the
beginning: when multiple failures can be tolerated, the recovery may be
able to continue and re-doing all that has already been done doesn't make
sense.
We already have the infrastructure to record where a recovery is up to
and restart from there, but it is not being used properly.
This is because:
- We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR,
which causes the recovery not be be checkpointed.
- We remove spares and then re-added them which loses important state
information.
The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't
needed. If there is an error, the relevant drive will be marked as
Faulty, and that is enough to ensure correct handling of the error. So we
first remove MD_RECOVERY_ERR, changing some of the uses of it to
MD_RECOVERY_INTR.
Then we cause the attempt to remove a non-faulty device from an array to
fail (unless recovery is impossible as the array is too degraded). Then
when remove_and_add_spares attempts to remove the devices on which
recovery can continue, it will fail, they will remain in place, and
recovery will continue on them as desired.
Issue: If we are halfway through rebuilding a spare and another drive
fails, and a new spare is immediately available, do we want to:
1/ complete the current rebuild, then go back and rebuild the new spare or
2/ restart the rebuild from the start and rebuild both devices in
parallel.
Both options can be argued for. The code currently takes option 2 as
a/ this requires least code change
b/ this results in a minimally-degraded array in minimal time.
Cc: "Eivind Sarto" <ivan@kasenna.com>
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>
2008-05-23 13:04:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-06-08 15:10:08 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:16 -07:00
|
|
|
|
2009-12-14 12:49:46 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-05 15:54:13 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
2008-04-30 00:52:30 -07:00
|
|
|
|
MD: use per-cpu counter for writes_pending
The 'writes_pending' counter is used to determine when the
array is stable so that it can be marked in the superblock
as "Clean". Consequently it needs to be updated frequently
but only checked for zero occasionally. Recent changes to
raid5 cause the count to be updated even more often - once
per 4K rather than once per bio. This provided
justification for making the updates more efficient.
So we replace the atomic counter a percpu-refcount.
This can be incremented and decremented cheaply most of the
time, and can be switched to "atomic" mode when more
precise counting is needed. As it is possible for multiple
threads to want a precise count, we introduce a
"sync_checker" counter to count the number of threads
in "set_in_sync()", and only switch the refcount back
to percpu mode when that is zero.
We need to be careful about races between set_in_sync()
setting ->in_sync to 1, and md_write_start() setting it
to zero. md_write_start() holds the rcu_read_lock()
while checking if the refcount is in percpu mode. If
it is, then we know a switch to 'atomic' will not happen until
after we call rcu_read_unlock(), in which case set_in_sync()
will see the elevated count, and not set in_sync to 1.
If it is not in percpu mode, we take the mddev->lock to
ensure proper synchronization.
It is no longer possible to quickly check if the count is zero, which
we previously did to update a timer or to schedule the md_thread.
So now we do these every time we decrement that counter, but make
sure they are fast.
mod_timer() already optimizes the case where the timeout value doesn't
actually change. We leverage that further by always rounding off the
jiffies to the timeout value. This may delay the marking of 'clean'
slightly, but ensure we only perform atomic operation here when absolutely
needed.
md_wakeup_thread() current always calls wake_up(), even if
THREAD_WAKEUP is already set. That too can be optimised to avoid
calls to wake_up().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-03-15 14:05:14 +11:00
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
2006-03-27 01:18:20 -08:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
2017-08-11 20:34:45 -07:00
|
|
|
|
md: always clear ->safemode when md_check_recovery gets the mddev lock.
If ->safemode == 1, md_check_recovery() will try to get the mddev lock
and perform various other checks.
If mddev->in_sync is zero, it will call set_in_sync, and clear
->safemode. However if mddev->in_sync is not zero, ->safemode will not
be cleared.
When md_check_recovery() drops the mddev lock, the thread is woken
up again. Normally it would just check if there was anything else to
do, find nothing, and go to sleep. However as ->safemode was not
cleared, it will take the mddev lock again, then wake itself up
when unlocking.
This results in an infinite loop, repeatedly calling
md_check_recovery(), which RCU or the soft-lockup detector
will eventually complain about.
Prior to commit 4ad23a976413 ("MD: use per-cpu counter for
writes_pending"), safemode would only be set to one when the
writes_pending counter reached zero, and would be cleared again
when writes_pending is incremented. Since that patch, safemode
is set more freely, but is not reliably cleared.
So in md_check_recovery() clear ->safemode before checking ->in_sync.
Fixes: 4ad23a976413 ("MD: use per-cpu counter for writes_pending")
Cc: stable@vger.kernel.org (4.12+)
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: David R <david@unsolicited.net>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
2017-08-08 16:56:36 +10:00
|
|
|
|
|
|
|
|
|
2008-08-05 15:54:13 +10:00
|
|
|
|
2015-06-17 12:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-05 15:54:13 +10:00
|
|
|
|
md: Allow devices to be re-added to a read-only array.
When assembling an array incrementally we might want to make
it device available when "enough" devices are present, but maybe
not "all" devices are present.
If the remaining devices appear before the array is actually used,
they should be added transparently.
We do this by using the "read-auto" mode where the array acts like
it is read-only until a write request arrives.
Current an add-device request switches a read-auto array to active.
This means that only one device can be added after the array is first
made read-auto. This isn't a problem for RAID5, but is not ideal for
RAID6 or RAID10.
Also we don't really want to switch the array to read-auto at all
when re-adding a device as this doesn't really imply any change.
So:
- remove the "md_update_sb()" call from add_new_disk(). This isn't
really needed as just adding a disk doesn't require a metadata
update. Instead, just set MD_CHANGE_DEVS. This will effect a
metadata update soon enough, once the array is not read-only.
- Allow the ADD_NEW_DISK ioctl to succeed without activating a
read-auto array, providing the MD_DISK_SYNC flag is set.
In this case, the device will be rejected if it cannot be added
with the correct device number, or has an incorrect event count.
- Teach remove_and_add_spares() to be careful about adding spares
when the array is read-only (or read-mostly) - only add devices
that are thought to be in-sync, and only do it if the array is
in-sync itself.
- In md_check_recovery, use remove_and_add_spares in the read-only
case, rather than open coding just the 'remove' part of it.
Reported-by: Martin Wilck <mwilck@arcor.de>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-04-24 11:42:42 +10:00
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-29 11:40:03 +10:00
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2015-07-17 11:57:30 +10:00
|
|
|
|
2013-12-12 10:13:33 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2008-08-05 15:54:13 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-21 10:50:59 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2017-03-15 14:05:14 +11:00
|
|
|
|
2014-12-15 12:56:56 +11:00
|
|
|
|
2005-06-21 17:17:11 -07:00
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2006-10-03 01:15:46 -07:00
|
|
|
|
2005-06-21 17:17:12 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2014-12-15 12:57:01 +11:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-24 10:23:14 +10:00
|
|
|
|
|
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-11 14:25:57 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2009-06-18 08:47:55 +10:00
|
|
|
|
|
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
2007-02-28 20:11:48 -08:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2013-04-24 11:42:41 +10:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
2008-08-07 10:02:47 -07:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
|
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
2005-11-08 21:39:26 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-22 13:55:08 +10:00
|
|
|
|
2005-06-21 17:17:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:05 +11:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-06-28 08:31:41 +10:00
|
|
|
|
2014-09-30 08:10:42 +10:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
md: Change handling of save_raid_disk and metadata update during recovery.
Since commit d70ed2e4fafdbef0800e739
MD: Allow restarting an interrupted incremental recovery.
we don't write out the metadata to devices while they are recovering.
This had a good reason, but has unfortunate consequences. This patch
changes things to make them work better.
At issue is what happens if the array is shut down while a recovery is
happening, particularly a bitmap-guided recovery.
Ideally the recovery should pick up where it left off.
However the metadata cannot represent the state "A recovery is in
process which is guided by the bitmap".
Before the above mentioned commit, we wrote metadata to the device
which said "this is being recovered and it is up to <here>". So after
a restart, a full recovery (not bitmap-guided) would happen from
where-ever it was up to.
After the commit the metadata wasn't updated so it still said "This
device is fully in sync with <this> event count". That leads to a
bitmap-based recovery following the whole bitmap, which should be a
lot less work than a full recovery from some starting point. So this
was an improvement.
However updates some metadata but not all leads to other problems.
In particular, the metadata written to the fully-up-to-date device
record that the array has all devices present (even though some are
recovering). So on restart, mdadm wants to find all devices and
expects them to have current event counts.
Obviously it doesn't (some have old event counts) so (when assembling
with --incremental) it waits indefinitely for the rest of the expected
devices.
It really is wrong to not update all the metadata together. Do that
is bound to cause confusion.
Instead, we should make it possible to record the truth in the
metadata. i.e. we need to be able to record that a device is being
recovered based on the bitmap.
We already have a Feature flag to say that recovery is happening. We
now add another one to say that it is a bitmap-based recovery.
With this we can remove the code that disables the write-out of
metadata on some devices.
So this patch:
- moves the setting of 'saved_raid_disk' from add_new_disk to
the validate_super methods. This makes sure it is always set
properly, both when adding a new device to an array, and when
assembling an array from a collection of devices.
- Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only
used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a
bitmap-based recovery is allowed.
This is only present in v1.x metadata. v0.90 doesn't support
devices which are in the middle of recovery at all.
- Only skips writing metadata to Faulty devices.
- Also allows rdev state to be set to "-insync" via sysfs.
This can be used for external-metadata arrays. When the
'role' is set the device is assumed to be in-sync. If, after
setting the role, we set the state to "-insync", the role is
moved to saved_raid_disk which effectively says the device is
partly in-sync with that slot and needs a bitmap recovery.
Cc: Andrei Warkentin <andreiw@vmware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-12-09 12:04:56 +11:00
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
2016-06-02 23:32:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
2015-06-12 20:05:04 +10:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-11 10:02:10 +11:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 16:15:38 +10:00
|
|
|
|
2013-04-24 11:42:43 +10:00
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2010-06-01 19:37:23 +10:00
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
2011-07-28 11:31:48 +10:00
|
|
|
|
|
|
|
|
|
2008-04-30 00:52:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2016-05-03 22:22:13 -04:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 16:26:08 +11:00
|
|
|
|
2016-12-08 15:48:19 -08:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2015-12-24 19:20:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
2012-05-21 09:27:00 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-21 16:26:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 11:31:46 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-05-05 16:16:09 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2011-09-23 10:40:45 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:37 +11:00
|
|
|
|
|
|
|
|
|
2012-04-24 10:23:16 +10:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:36:08 +10:00
|
|
|
|
|
|
|
|
|
2012-03-19 12:46:37 +11:00
|
|
|
|
2011-09-23 10:40:45 +01:00
|
|
|
|
2012-03-19 12:46:37 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-19 12:46:37 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-05-05 16:16:09 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:23:17 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-29 01:02:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-05-05 16:16:09 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
2011-01-25 14:35:54 +01:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-31 13:54:54 +10:00
|
|
|
|
2006-10-03 01:15:59 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-14 00:34:09 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-10-13 11:55:12 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
2014-06-07 01:53:00 -05:00
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-07 01:53:00 -05:00
|
|
|
|
2017-03-01 16:42:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-01 13:20:27 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2016-05-02 11:33:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-07 01:53:00 -05:00
|
|
|
|
|
|
|
|
|
2015-10-22 16:01:25 +11:00
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
|
|
|
|
|
2015-08-21 10:33:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-07 01:53:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
2016-06-08 09:20:16 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-08 09:20:16 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
2016-06-08 09:20:16 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:45:26 +11:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-08 09:20:16 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-14 14:26:54 -07:00
|
|
|
|
2007-07-17 04:06:11 -07:00
|
|
|
|
2016-09-14 14:26:54 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-30 15:52:29 +10:00
|
|
|
|
2008-03-04 14:29:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-08 09:20:16 -07:00
|
|
|
|
2007-10-16 23:30:52 -07:00
|
|
|
|
2016-11-02 14:16:49 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-10 02:20:50 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-11 16:47:53 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-09 14:33:51 +10:00
|
|
|
|
2005-06-20 21:15:16 -07:00
|
|
|
|
2014-07-31 13:54:54 +10:00
|
|
|
|
2006-10-03 01:15:59 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-31 14:27:02 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-09 14:33:51 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-09 14:33:51 +10:00
|
|
|
|
2008-02-06 01:39:58 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-06 13:41:39 +11:00
|
|
|
|
md: make devices disappear when they are no longer needed.
Currently md devices, once created, never disappear until the module
is unloaded. This is essentially because the gendisk holds a
reference to the mddev, and the mddev holds a reference to the
gendisk, this a circular reference.
If we drop the reference from mddev to gendisk, then we need to ensure
that the mddev is destroyed when the gendisk is destroyed. However it
is not possible to hook into the gendisk destruction process to enable
this.
So we drop the reference from the gendisk to the mddev and destroy the
gendisk when the mddev gets destroyed. However this has a
complication.
Between the call
__blkdev_get->get_gendisk->kobj_lookup->md_probe
and the call
__blkdev_get->md_open
there is no obvious way to hold a reference on the mddev any more, so
unless something is done, it will disappear and gendisk will be
destroyed prematurely.
Also, once we decide to destroy the mddev, there will be an unlockable
moment before the gendisk is unlinked (blk_unregister_region) during
which a new reference to the gendisk can be created. We need to
ensure that this reference can not be used. i.e. the ->open must
fail.
So:
1/ in md_probe we set a flag in the mddev (hold_active) which
indicates that the array should be treated as active, even
though there are no references, and no appearance of activity.
This is cleared by md_release when the device is closed if it
is no longer needed.
This ensures that the gendisk will survive between md_probe and
md_open.
2/ In md_open we check if the mddev we expect to open matches
the gendisk that we did open.
If there is a mismatch we return -ERESTARTSYS and modify
__blkdev_get to retry from the top in that case.
In the -ERESTARTSYS sys case we make sure to wait until
the old gendisk (that we succeeded in opening) is really gone so
we loop at most once.
Some udev configurations will always open an md device when it first
appears. If we allow an md device that was just created by an open
to disappear on an immediate close, then this can race with such udev
configurations and result in an infinite loop the device being opened
and closed, then re-open due to the 'ADD' even from the first open,
and then close and so on.
So we make sure an md device, once created by an open, remains active
at least until some md 'ioctl' has been made on it. This means that
all normal usage of md devices will allow them to disappear promptly
when not needed, but the worst that an incorrect usage will do it
cause an inactive md device to be left in existence (it can easily be
removed).
As an array can be stopped by writing to a sysfs attribute
echo clear > /sys/block/mdXXX/md/array_state
we need to use scheduled work for deleting the gendisk and other
kobjects. This allows us to wait for any pending gendisk deletion to
complete by simply calling flush_scheduled_work().
Signed-off-by: NeilBrown <neilb@suse.de>
2009-01-09 08:31:10 +11:00
|
|
|
|
2017-02-06 13:41:39 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-10-15 15:36:08 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-07-09 11:56:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-16 14:02:38 +03:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 04:44:18 -07:00
|
|
|
|
|
|
|
|
|
2009-01-09 08:31:10 +11:00
|
|
|
|
2017-04-12 16:26:13 +10:00
|
|
|
|
[PATCH] md: allow md arrays to be started read-only (module parameter).
When an md array is started, the superblock will be written, and resync may
commense. This is not good if you want to be completely read-only as, for
example, when preparing to resume from a suspend-to-disk image.
So introduce a module parameter "start_ro" which can be set
to '1' at boot, at module load, or via
/sys/module/md_mod/parameters/start_ro
When this is set, new arrays get an 'auto-ro' mode, which disables all
internal io (superblock updates, resync, recovery) and is automatically
switched to 'rw' when the first write request arrives.
The array can be set to true 'ro' mode using 'mdadm -r' before the first
write request, or resync can be started without a write using 'mdadm -w'.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-08 21:39:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-14 12:49:58 +11:00
|
|
|
|
2005-08-04 12:53:32 -07:00
|
|
|
|
2005-08-26 18:34:15 -07:00
|
|
|
|
