From: NeilBrown <neilb@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-raid@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: [PATCH md 010 of 10] Document sysfs usage of md, and make a couple of small refinements.
Date: Wed, 2 Nov 2005 21:16:03 +1100 [thread overview]
Message-ID: <1051102101603.23981@suse.de> (raw)
In-Reply-To: 20051102205640.22689.patches@notabene
Document in Documentation/md.txt the files that now appear in sysfs,
and make a couple of small refinements to exactly when 'level' and
'raid_disks' are empty, to make it match the documentation.
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./Documentation/md.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++++
./drivers/md/md.c | 4 +
2 files changed, 122 insertions(+), 1 deletion(-)
diff ./Documentation/md.txt~current~ ./Documentation/md.txt
--- ./Documentation/md.txt~current~ 2005-11-02 17:32:28.000000000 +1100
+++ ./Documentation/md.txt 2005-11-02 17:33:38.000000000 +1100
@@ -116,3 +116,122 @@ and it's role in the array.
Once started with RUN_ARRAY, uninitialized spares can be added with
HOT_ADD_DISK.
+
+
+
+MD devices in sysfs
+-------------------
+md devices appear in sysfs (/sys) as regular block devices,
+e.g.
+ /sys/block/md0
+
+Each 'md' device will contain a subdirectory called 'md' which
+contains further md-specific information about the device.
+
+All md devices contain:
+ level
+ a text file indicating the 'raid level'. This may be a standard
+ numerical level prefixed by "RAID-" - e.g. "RAID-5", or some
+ other name such as "linear" or "multipath".
+ If no raid level has been set yet (array is still being
+ assembled), this file will be empty.
+
+ 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.
+
+As component devices are added to an md array, they appear in the 'md'
+directory as new directories named
+ dev-XXX
+where XXX is a name that the kernel knows for the device, e.g. hdb1.
+Each directory contains:
+
+ block
+ a symlink to the block device in /sys/block, e.g.
+ /sys/block/md0/md/dev-hdb1/block -> ../../../../block/hdb/hdb1
+
+ super
+ A file containing an image of the superblock read from, or
+ written to, that device.
+
+ state
+ A file recording the current state of the device in the array
+ which can be a comma separated list of
+ faulty - device has been kicked from active use due to
+ a detected fault
+ in_sync - device is a fully in-sync member of the array
+ spare - device is working, but not a full member.
+ This includes spares that are in the process
+ of being recoverred to
+ This list make grow in future.
+
+
+An active md device will also contain and entry for each active device
+in the array. These are named
+
+ rdNN
+
+where 'NN' is the possition in the array, starting from 0.
+So for a 3 drive array there will be rd0, rd1, rd2.
+These are symbolic links to the appropriate 'dev-XXX' entry.
+Thus, for example,
+ cat /sys/block/md*/md/rd*/state
+will show 'in_sync' on every line.
+
+
+
+Active md devices for levels that support data redundancy (1,4,5,6)
+also have
+
+ sync_action
+ a text file that can be used to monitor and control the rebuild
+ process. It contains one word which can be one of:
+ resync - redundancy is being recalculated after unclean
+ shutdown or creation
+ recover - a hot spare is being built to replace a
+ failed/missing device
+ idle - nothing is happening
+ check - A full check of redundancy was requested and is
+ happening. This reads all block and checks
+ them. A repair may also happen for some raid
+ levels.
+ repair - A full check and repair is happening. This is
+ similar to 'resync', but was requested by the
+ user, and the write-intent bitmap is NOT used to
+ optimise the process.
+
+ This file is writable, and each of the strings that could be
+ read are meaningful for writing.
+
+ 'idle' will stop an active resync/recovery etc. There is no
+ guarantee that another resync/recovery may not be automatically
+ started again, though some event will be needed to trigger
+ this.
+ 'resync' or 'recovery' can be used to restart the
+ corresponding operation if it was stopped with 'idle'.
+ 'check' and 'repair' will start the appropriate process
+ providing the current state is 'idle'.
+
+ mismatch_count
+ When performing 'check' and 'repair', and possibly when
+ performing 'resync', md will count the number of errors that are
+ found. The count in 'mismatch_cnt' is the number of sectors
+ that were re-written, or (for 'check') would have been
+ re-written. As most raid levels work in units of pages rather
+ than sectors, this my be larger than the number of actual errors
+ by a factor of the number of sectors in a page.
+
+Each active md device may also have attributes specific to the
+personality module that manages it.
+These are specific to the implementation of the module and could
+change substantially if the implementation changes.
+
+These currently include
+
+ stripe_cache_size (currently raid5 only)
+ number of entries in the stripe cache. This is writable, but
+ there are upper and lower limits (32768, 16). Default is 128.
+ strip_cache_active (currently raid5 only)
+ number of active entries in the stripe cache
diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~ 2005-11-02 17:33:35.000000000 +1100
+++ ./drivers/md/md.c 2005-11-02 17:33:38.000000000 +1100
@@ -1727,7 +1727,7 @@ static ssize_t
level_show(mddev_t *mddev, char *page)
{
mdk_personality_t *p = mddev->pers;
- if (p == NULL)
+ if (p == NULL && mddev->raid_disks == 0)
return 0;
if (mddev->level >= 0)
return sprintf(page, "RAID-%d\n", mddev->level);
@@ -1740,6 +1740,8 @@ static struct md_sysfs_entry md_level =
static ssize_t
raid_disks_show(mddev_t *mddev, char *page)
{
+ if (mddev->raid_disks == 0)
+ return 0;
return sprintf(page, "%d\n", mddev->raid_disks);
}
next prev parent reply other threads:[~2005-11-02 10:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 10:14 [PATCH md 000 of 10] Introduction NeilBrown
2005-11-02 10:14 ` [PATCH md 001 of 10] Make sure /block link in /sys/.../md/ goes to correct devices NeilBrown
2005-11-02 21:46 ` Greg KH
2005-11-02 10:14 ` [PATCH md 002 of 10] Make manual repair work for raid1 NeilBrown
2005-11-02 10:15 ` [PATCH md 003 of 10] Make sure a user-request sync of raid5 ignores intent bitmap NeilBrown
2005-11-02 10:15 ` [PATCH md 004 of 10] Fix some locking and module refcounting issues with md's use of sysfs NeilBrown
2005-11-02 21:47 ` Greg KH
2005-11-02 10:15 ` [PATCH md 005 of 10] Split off some md attributes in sysfs to a separate group NeilBrown
2005-11-02 21:48 ` Greg KH
2005-11-02 10:15 ` [PATCH md 006 of 10] Only try to print recovery/resync status for personalities that support recovery NeilBrown
2005-11-02 10:15 ` [PATCH md 007 of 10] Ignore auto-readonly flag for arrays where it isn't meaningful NeilBrown
2005-11-02 10:15 ` [PATCH md 008 of 10] Complete conversion of md to use kthreads NeilBrown
2005-11-02 10:15 ` [PATCH md 009 of 10] Improve 'scan_mode' and rename it to 'sync_action' NeilBrown
2005-11-02 21:49 ` Greg KH
2005-11-02 10:16 ` NeilBrown [this message]
2005-11-02 21:50 ` [PATCH md 010 of 10] Document sysfs usage of md, and make a couple of small refinements Greg KH
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=1051102101603.23981@suse.de \
--to=neilb@suse.de \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--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).