{
    "content": [
        {
            "type": "text",
            "text": "# MDMON (man)\n\n## NAME\n\nmdmon - monitor MD external metadata arrays\n\n## SYNOPSIS\n\nmdmon [--all] [--takeover] [--foreground] CONTAINER\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **OVERVIEW**\n- **DESCRIPTION** (2 subsections)\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": "man",
        "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 currently monitoring the ar‐ ray. 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 monitoring each of them if appropriate. This is normally used with --takeover late in the boot sequence. A sep‐ arate mdmon process is started for each container as the --all argument is over-writ‐ ten with the name of the container. To allow for containers with names longer than 5 characters, this argument can be arbitrarily extended, e.g. to --all-active-arrays. Note that mdmon is automatically started by mdadm when needed and so does not need to be consid‐ ered 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 filesystem."
            }
        ],
        "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": 3,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "OVERVIEW",
                "lines": 7,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 1,
                "subsections": [
                    {
                        "name": "Metadata updates:",
                        "lines": 59
                    },
                    {
                        "name": "Containers:",
                        "lines": 20
                    }
                ]
            },
            {
                "name": "OPTIONS",
                "lines": 4,
                "subsections": [
                    {
                        "name": "--foreground",
                        "lines": 3,
                        "long": "--foreground"
                    },
                    {
                        "name": "--takeover",
                        "lines": 20,
                        "long": "--takeover"
                    }
                ]
            },
            {
                "name": "START UP AND SHUTDOWN",
                "lines": 22,
                "subsections": []
            },
            {
                "name": "EXAMPLES",
                "lines": 5,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 5,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "mdmon - monitor MD external metadata arrays\n\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "mdmon [--all] [--takeover] [--foreground] CONTAINER\n\n",
                "subsections": []
            },
            "OVERVIEW": {
                "content": "The  2.6.27 kernel brings the ability to support external metadata arrays.  External metadata\nimplies that user space handles all updates to the metadata.  The kernel's responsibility  is\nto  notify  user  space when a \"metadata event\" occurs, like disk failures and clean-to-dirty\ntransitions.  The kernel, in important cases, waits for user space to take  action  on  these\nnotifications.\n\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "",
                "subsections": [
                    {
                        "name": "Metadata updates:",
                        "content": "To  service  metadata  update  requests a daemon, mdmon, is introduced.  Mdmon is tasked with\npolling the sysfs namespace looking for changes in arraystate,  syncaction,  and  per  disk\nstate  attributes.   When  a  change is detected it calls a per metadata type handler to make\nmodifications to the metadata.  The following actions are taken:\n\narraystate - inactive\nClear the dirty bit for the volume and let the array be stopped\n\narraystate - write pending\nSet the dirty bit for the array and then set arraystate to active.  Writes are\nblocked until userspace writes active.\n\narraystate - active-idle\nThe  safe mode timer has expired so set array state to clean to block writes to\nthe 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.  mdmon  takes  one  of  the\nthree actions:\n\n1/     Transition  the  array  to  read-auto keeping the dirty bit clear if the\nmetadata handler determines that the array does not  need  resyncing  or\nother modification\n\n2/     Transition  the  array  to  active  if the metadata handler determines a\nresync or some other manipulation is necessary\n\n3/     Leave the array read-only if the volume is marked to not  be  monitored;\nfor  example, the metadata version has been set to \"external:-dev/md127\"\ninstead of \"external:/dev/md127\"\n\nsyncaction - resync-to-idle\nNotify the metadata handler that a resync may  have  completed.   If  a  resync\nprocess  is idled before it completes this event allows the metadata handler to\ncheckpoint resync.\n\nsyncaction - recover-to-idle\nA spare may have completed rebuilding so tell the metadata  handler  about  the\nstate  of  each  disk.  This is the metadata handler's opportunity to clear any\n\"out-of-sync\" bits and clear the  volume's  degraded  status.   If  a  recovery\nprocess  is idled before it completes this event allows the metadata handler to\ncheckpoint recovery.\n\n<disk>/state - faulty\nA disk failure kicks off a series of events.  First, notify the  metadata  han‐\ndler  that  a  disk  has failed, and then notify the kernel that it can unblock\nwrites that were dependent on this disk.  After unblocking the kernel this disk\nis set to be removed+ from the member array.  Finally the disk is marked failed\nin all other member arrays in the container.\n\n+ Note This behavior differs slightly from native MD arrays  where  removal  is\nreserved  for  a  mdadm --remove event.  In the external metadata case the con‐\ntainer holds the final reference on a block device and a mdadm  --remove  <con‐‐\ntainer> <victim> call is still required.\n\n"
                    },
                    {
                        "name": "Containers:",
                        "content": "External  metadata formats, like DDF, differ from the native MD metadata formats in that they\ndefine a set of disks and a series of sub-arrays within those disks.  MD metadata in compari‐\nson  defines a 1:1 relationship between a set of block devices and a RAID array.  For example\nto create 2 arrays at different RAID levels on a single set of disks,  MD  metadata  requires\nthe  disks  be  partitioned  and then each array can be created with a subset of those parti‐\ntions.  The supported external formats perform this disk carving internally.\n\nContainer devices simply hold references to all member disks and allow tools  like  mdmon  to\ndetermine which active arrays belong to which container.  Some array management commands like\ndisk removal and disk add are now only valid at the container  level.   Attempts  to  perform\nthese actions on member arrays are blocked with error messages like:\n\n\"mdadm:  Cannot remove disks from a 'member' array, perform this operation on the par‐\nent container\"\n\nContainers are identified in /proc/mdstat with a metadata version string  \"external:<metadata\nname>\".  Member  devices  are identified by \"external:/<container device>/<member index>\", or\n\"external:-<container device>/<member index>\" if the array is to remain readonly.\n\n"
                    }
                ]
            },
            "OPTIONS": {
                "content": "CONTAINER\nThe container device to monitor.  It can be a full path like /dev/md/container,  or  a\nsimple md device name like md127.\n",
                "subsections": [
                    {
                        "name": "--foreground",
                        "content": "Normally,  mdmon  will  fork  and continue in the background.  Adding this option will\nskip that step and run mdmon in the foreground.\n",
                        "long": "--foreground"
                    },
                    {
                        "name": "--takeover",
                        "content": "This instructs mdmon to replace any active mdmon which is currently monitoring the ar‐\nray.   This  is primarily used late in the boot process to replace any mdmon which was\nstarted from an initramfs before the root filesystem was mounted.  This avoids holding\na  reference  on  that  initramfs indefinitely and ensures that the pid and sock files\nused to communicate with mdmon are in a standard place.\n\n--all  This tells mdmon to find any active containers and start monitoring each  of  them  if\nappropriate.  This is normally used with --takeover late in the boot sequence.  A sep‐\narate mdmon process is started for each container as the --all argument is  over-writ‐\nten  with the name of the container.  To allow for containers with names longer than 5\ncharacters, this argument can be arbitrarily extended, e.g. to --all-active-arrays.\n\n\n\nNote that\nmdmon is automatically started by mdadm when needed and so does not need to be consid‐\nered  when  working with RAID arrays.  The only times it is run other than by mdadm is\nwhen the boot scripts need to restart it after mounting the new root filesystem.\n\n",
                        "long": "--takeover"
                    }
                ]
            },
            "START UP AND SHUTDOWN": {
                "content": "As mdmon needs to be running whenever any filesystem on the monitored device is mounted there\nare  special  considerations  when the root filesystem is mounted from an mdmon monitored de‐\nvice.  Note that in general mdmon is needed even if the filesystem is  mounted  read-only  as\nsome  filesystems can still write to the device in those circumstances, for example to replay\na journal after an unclean shutdown.\n\nWhen the array is assembled by the initramfs code, mdadm will automatically  start  mdmon  as\nrequired.   This  means  that  mdmon  must  be installed on the initramfs and there must be a\nwritable filesystem (typically tmpfs) in which mdmon can create a .pid and .sock  file.   The\nparticular filesystem to use is given to mdmon at compile time and defaults to /run/mdadm.\n\nThis filesystem must persist through to shutdown time.\n\nAfter the final root filesystem has be instantiated (usually with pivotroot) mdmon should be\nrun with --all --takeover so that the mdmon running from the initramfs can be  replaced  with\none running in the main root, and so the memory used by the initramfs can be released.\n\nAt  shutdown time, mdmon should not be killed along with other processes.  Also as it holds a\nfile (socket actually) open in /dev (by default) it will not be possible to unmount  /dev  if\nit is a separate filesystem.\n\n",
                "subsections": []
            },
            "EXAMPLES": {
                "content": "mdmon --all-active-arrays --takeover\nAny mdmon which is currently running is killed and a new instance is started.  This should be\nrun during in the boot sequence if an initramfs was used, so that any mdmon running from  the\ninitramfs will not hold the initramfs active.\n",
                "subsections": []
            },
            "SEE ALSO": {
                "content": "mdadm(8), md(4).\n\n\n\nv4.2                                                                                        MDMON(8)",
                "subsections": []
            }
        }
    }
}