From: NeilBrown <neilb@suse.de>
To: linux-raid@vger.kernel.org
Cc: NeilBrown <neilb@suse.de>
Subject: [md PATCH 04/14] Documentation/md.txt update
Date: Tue, 31 Mar 2009 15:54:43 +1100 [thread overview]
Message-ID: <20090331045443.2589.62526.stgit@notabene.brown> (raw)
In-Reply-To: <20090331044827.2589.95894.stgit@notabene.brown>
Update md.txt to reflect recent changes in a number of sysfs
attributes.
Signed-off-by: NeilBrown <neilb@suse.de>
---
Documentation/md.txt | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 1da9d1b..4edd39e 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -164,15 +164,19 @@ All md devices contain:
raid_disks
a text file with a simple number indicating the number of devices
in a fully functional array. If this is not yet known, the file
- will be empty. If an array is being resized (not currently
- possible) this will contain the larger of the old and new sizes.
- Some raid level (RAID1) allow this value to be set while the
- array is active. This will reconfigure the array. Otherwise
- it can only be set while assembling an array.
+ will be empty. If an array is being resized this will contain
+ the new number of devices.
+ Some raid levels allow this value to be set while the array is
+ active. This will reconfigure the array. Otherwise it can only
+ be set while assembling an array.
+ A change to this attribute will not be permitted if it would
+ reduce the size of the array. To reduce the number of drives
+ in an e.g. raid5, the array size must first be reduced by
+ setting the 'array_size' attribute.
chunk_size
- This is the size if bytes for 'chunks' and is only relevant to
- raid levels that involve striping (1,4,5,6,10). The address space
+ This is the size in bytes for 'chunks' and is only relevant to
+ raid levels that involve striping (0,4,5,6,10). The address space
of the array is conceptually divided into chunks and consecutive
chunks are striped onto neighbouring devices.
The size should be at least PAGE_SIZE (4k) and should be a power
@@ -183,6 +187,20 @@ All md devices contain:
simply a number that is interpretted differently by different
levels. It can be written while assembling an array.
+ array_size
+ This can be used to artificially constrain the available space in
+ the array to be less than is actually available on the combined
+ devices. Writing a number (in Kilobytes) which is less than
+ the available size will set the size. Any reconfiguration of the
+ array (e.g. adding devices) will not cause the size to change.
+ Writing the word 'default' will cause the effective size of the
+ array to be whatever size is actually available based on
+ 'level', 'chunk_size' and 'component_size'.
+
+ This can be used to reduce the size of the array before reducing
+ the number of devices in a raid4/5/6, or to support external
+ metadata formats which mandate such clipping.
+
reshape_position
This is either "none" or a sector number within the devices of
the array where "reshape" is up to. If this is set, the three
@@ -207,6 +225,11 @@ All md devices contain:
about the array. It can be 0.90 (traditional format), 1.0, 1.1,
1.2 (newer format in varying locations) or "none" indicating that
the kernel isn't managing metadata at all.
+ Alternately it can be "external:" followed by a string which
+ is set by user-space. This indicates that metadata is managed
+ by a user-space program. Any device failure or other event that
+ requires a metadata update will cause array activity to be
+ suspended until the event is acknowledged.
resync_start
The point at which resync should start. If no resync is needed,
next prev parent reply other threads:[~2009-03-31 4:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-31 4:54 [md PATCH 00/14] Final set of patches head for 2.6.30 NeilBrown
2009-03-31 4:54 ` [md PATCH 02/14] md/raid5: change reshape-progress measurement to cope with reshaping backwards NeilBrown
2009-03-31 4:54 ` [md PATCH 01/14] md: add explicit method to signal the end of a reshape NeilBrown
2009-03-31 4:54 ` [md PATCH 06/14] md/raid5: prepare for allowing reshape to change chunksize NeilBrown
2009-03-31 4:54 ` [md PATCH 05/14] md/raid5: clearly differentiate 'before' and 'after' stripes during reshape NeilBrown
2009-03-31 4:54 ` [md PATCH 03/14] md: allow number of drives in raid5 to be reduced NeilBrown
2009-03-31 4:54 ` [md PATCH 09/14] md/raid5: allow layout and chunksize to be changed on active array NeilBrown
2009-03-31 4:54 ` [md PATCH 07/14] md/raid5: prepare for allowing reshape to change layout NeilBrown
2009-03-31 4:54 ` [md PATCH 08/14] md/raid5: reshape using largest of old and new chunk size NeilBrown
2009-03-31 4:54 ` NeilBrown [this message]
2009-03-31 4:54 ` [md PATCH 14/14] md/raid5 revise rules for when to update metadata during reshape NeilBrown
2009-03-31 4:54 ` [md PATCH 11/14] md/raid5: be more careful about write ordering when reshaping NeilBrown
2009-03-31 4:54 ` [md PATCH 13/14] md/raid5: minor code cleanups in make_request NeilBrown
2009-03-31 4:54 ` [md PATCH 10/14] md: don't display meaningless values in sysfs files resync_start and sync_speed NeilBrown
2009-03-31 4:54 ` [md PATCH 12/14] md: remove CONFIG_MD_RAID_RESHAPE config option NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090331045443.2589.62526.stgit@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).