{ "content": [ { "type": "text", "text": "# mdmon (info)\n\n## NAME\n\nmdmon - monitor MD external metadata arrays\n\n## SYNOPSIS\n\nmdmon [--all] [--takeover] [--foreground] CONTAINER\n\n## DESCRIPTION\n\nMetadata updates:\nTo service metadata update requests a daemon, mdmon, is introduced.\nMdmon is tasked with polling the sysfs namespace looking for changes in\narraystate, syncaction, and per disk state attributes. When a change\nis detected it calls a per metadata type handler to make modifications\nto the metadata. The following actions are taken:\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **OVERVIEW**\n- **DESCRIPTION**\n- **OPTIONS** (2 subsections)\n- **START UP AND SHUTDOWN**\n- **EXAMPLES**\n- **SEE ALSO**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "mdmon", "section": "", "mode": "info", "summary": "mdmon - monitor MD external metadata arrays", "synopsis": "mdmon [--all] [--takeover] [--foreground] CONTAINER", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [ { "flag": "", "long": "--foreground", "arg": null, "description": "Normally, mdmon will fork and continue in the background. Adding this option will skip that step and run mdmon in the foreground." }, { "flag": "", "long": "--takeover", "arg": null, "description": "This instructs mdmon to replace any active mdmon which is cur- rently monitoring the array. This is primarily used late in the boot process to replace any mdmon which was started from an initramfs before the root filesystem was mounted. This avoids holding a reference on that initramfs indefinitely and ensures that the pid and sock files used to communicate with mdmon are in a standard place. --all This tells mdmon to find any active containers and start moni- toring each of them if appropriate. This is normally used with --takeover late in the boot sequence. A separate mdmon process is started for each container as the --all argument is over- written with the name of the container. To allow for containers with names longer than 5 characters, this argument can be arbi- trarily extended, e.g. to --all-active-arrays. Note that mdmon is automatically started by mdadm when needed and so does not need to be considered when working with RAID arrays. The only times it is run other than by mdadm is when the boot scripts need to restart it after mounting the new root filesys- tem." } ], "examples": [ "mdmon --all-active-arrays --takeover", "Any mdmon which is currently running is killed and a new instance is", "started. This should be run during in the boot sequence if an", "initramfs was used, so that any mdmon running from the initramfs will", "not hold the initramfs active." ], "see_also": [ { "name": "mdadm", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/mdadm/8/json" }, { "name": "md", "section": "4", "url": "https://www.chedong.com/phpMan.php/man/md/4/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 2, "subsections": [] }, { "name": "OVERVIEW", "lines": 7, "subsections": [] }, { "name": "DESCRIPTION", "lines": 94, "subsections": [] }, { "name": "OPTIONS", "lines": 4, "subsections": [ { "name": "--foreground", "lines": 4, "long": "--foreground" }, { "name": "--takeover", "lines": 23, "long": "--takeover" } ] }, { "name": "START UP AND SHUTDOWN", "lines": 26, "subsections": [] }, { "name": "EXAMPLES", "lines": 6, "subsections": [] }, { "name": "SEE ALSO", "lines": 3, "subsections": [] } ], "sections": { "NAME": { "content": "mdmon - monitor MD external metadata arrays\n", "subsections": [] }, "SYNOPSIS": { "content": "mdmon [--all] [--takeover] [--foreground] CONTAINER\n", "subsections": [] }, "OVERVIEW": { "content": "The 2.6.27 kernel brings the ability to support external metadata ar-\nrays. External metadata implies that user space handles all updates to\nthe metadata. The kernel's responsibility is to notify user space when\na \"metadata event\" occurs, like disk failures and clean-to-dirty tran-\nsitions. The kernel, in important cases, waits for user space to take\naction on these notifications.\n", "subsections": [] }, "DESCRIPTION": { "content": "Metadata updates:\nTo service metadata update requests a daemon, mdmon, is introduced.\nMdmon is tasked with polling the sysfs namespace looking for changes in\narraystate, syncaction, and per disk state attributes. When a change\nis detected it calls a per metadata type handler to make modifications\nto the metadata. The following actions are taken:\n\narraystate - inactive\nClear the dirty bit for the volume and let the array be\nstopped\n\narraystate - write pending\nSet the dirty bit for the array and then set arraystate\nto active. Writes are blocked until userspace writes ac-\ntive.\n\narraystate - active-idle\nThe safe mode timer has expired so set array state to\nclean to block writes to the array\n\narraystate - clean\nClear the dirty bit for the volume\n\narraystate - read-only\nThis is the initial state that all arrays start at. md-\nmon takes one of the three actions:\n\n1/ Transition the array to read-auto keeping the\ndirty bit clear if the metadata handler determines\nthat the array does not need resyncing or other\nmodification\n\n2/ Transition the array to active if the metadata\nhandler determines a resync or some other manipu-\nlation is necessary\n\n3/ Leave the array read-only if the volume is marked\nto not be monitored; for example, the metadata\nversion has been set to \"external:-dev/md127\" in-\nstead of \"external:/dev/md127\"\n\nsyncaction - resync-to-idle\nNotify the metadata handler that a resync may have com-\npleted. If a resync process is idled before it completes\nthis event allows the metadata handler to checkpoint\nresync.\n\nsyncaction - recover-to-idle\nA spare may have completed rebuilding so tell the meta-\ndata handler about the state of each disk. This is the\nmetadata handler's opportunity to clear any \"out-of-sync\"\nbits and clear the volume's degraded status. If a recov-\nery process is idled before it completes this event al-\nlows the metadata handler to checkpoint recovery.\n\n/state - faulty\nA disk failure kicks off a series of events. First, no-\ntify the metadata handler that a disk has failed, and\nthen notify the kernel that it can unblock writes that\nwere dependent on this disk. After unblocking the kernel\nthis disk is set to be removed+ from the member array.\nFinally the disk is marked failed in all other member ar-\nrays in the container.\n\n+ Note This behavior differs slightly from native MD ar-\nrays where removal is reserved for a mdadm --remove\nevent. In the external metadata case the container holds\nthe final reference on a block device and a mdadm --re-\nmove call is still required.\n\nContainers:\nExternal metadata formats, like DDF, differ from the native MD metadata\nformats in that they define a set of disks and a series of sub-arrays\nwithin those disks. MD metadata in comparison defines a 1:1 relation-\nship between a set of block devices and a RAID array. For example to\ncreate 2 arrays at different RAID levels on a single set of disks, MD\nmetadata requires the disks be partitioned and then each array can be\ncreated with a subset of those partitions. The supported external for-\nmats perform this disk carving internally.\n\nContainer devices simply hold references to all member disks and allow\ntools like mdmon to determine which active arrays belong to which con-\ntainer. Some array management commands like disk removal and disk add\nare now only valid at the container level. Attempts to perform these\nactions on member arrays are blocked with error messages like:\n\n\"mdadm: Cannot remove disks from a 'member' array, perform this\noperation on the parent container\"\n\nContainers are identified in /proc/mdstat with a metadata version\nstring \"external:\". Member devices are identified by\n\"external://\", or \"external:-/\" if the array is to remain readonly.\n", "subsections": [] }, "OPTIONS": { "content": "CONTAINER\nThe container device to monitor. It can be a full path like\n/dev/md/container, or a simple md device name like md127.\n", "subsections": [ { "name": "--foreground", "content": "Normally, mdmon will fork and continue in the background.\nAdding this option will skip that step and run mdmon in the\nforeground.\n", "long": "--foreground" }, { "name": "--takeover", "content": "This instructs mdmon to replace any active mdmon which is cur-\nrently monitoring the array. This is primarily used late in the\nboot process to replace any mdmon which was started from an\ninitramfs before the root filesystem was mounted. This avoids\nholding a reference on that initramfs indefinitely and ensures\nthat the pid and sock files used to communicate with mdmon are\nin a standard place.\n\n--all This tells mdmon to find any active containers and start moni-\ntoring each of them if appropriate. This is normally used with\n--takeover late in the boot sequence. A separate mdmon process\nis started for each container as the --all argument is over-\nwritten with the name of the container. To allow for containers\nwith names longer than 5 characters, this argument can be arbi-\ntrarily extended, e.g. to --all-active-arrays.\n\nNote that\nmdmon is automatically started by mdadm when needed and so does\nnot need to be considered when working with RAID arrays. The\nonly times it is run other than by mdadm is when the boot\nscripts need to restart it after mounting the new root filesys-\ntem.\n", "long": "--takeover" } ] }, "START UP AND SHUTDOWN": { "content": "As mdmon needs to be running whenever any filesystem on the monitored\ndevice is mounted there are special considerations when the root\nfilesystem is mounted from an mdmon monitored device. Note that in\ngeneral mdmon is needed even if the filesystem is mounted read-only as\nsome filesystems can still write to the device in those circumstances,\nfor example to replay a journal after an unclean shutdown.\n\nWhen the array is assembled by the initramfs code, mdadm will automati-\ncally start mdmon as required. This means that mdmon must be installed\non the initramfs and there must be a writable filesystem (typically\ntmpfs) in which mdmon can create a .pid and .sock file. The particular\nfilesystem to use is given to mdmon at compile time and defaults to\n/run/mdadm.\n\nThis filesystem must persist through to shutdown time.\n\nAfter the final root filesystem has be instantiated (usually with\npivotroot) mdmon should be run with --all --takeover so that the mdmon\nrunning from the initramfs can be replaced with one running in the main\nroot, and so the memory used by the initramfs can be released.\n\nAt shutdown time, mdmon should not be killed along with other pro-\ncesses. Also as it holds a file (socket actually) open in /dev (by de-\nfault) it will not be possible to unmount /dev if it is a separate\nfilesystem.\n", "subsections": [] }, "EXAMPLES": { "content": "mdmon --all-active-arrays --takeover\nAny mdmon which is currently running is killed and a new instance is\nstarted. This should be run during in the boot sequence if an\ninitramfs was used, so that any mdmon running from the initramfs will\nnot hold the initramfs active.\n", "subsections": [] }, "SEE ALSO": { "content": "mdadm(8), md(4).\n\nv4.2 MDMON(8)", "subsections": [] } } } }