OCF_HEARTBEAT_MDRAID(7)

πŸ’– ocf_heartbeat_mdraid πŸ’–

okay so bestie, welcome to OCF_HEARTBEAT_MDRAID(7) β€” the manual page for ocf_heartbeat_mdraid, aka the resource agent that manages Linux software RAID (MD) devices on shared storage. pull up a chair, grab a boba, and let's get into it 🧚✨


🌸 SYNOPSIS 🌸

mdraid [start | stop | monitor | meta-data | validate-all]

that's it. that's the whole vibe check. five actions, no cap πŸ’…


✨ DESCRIPTION ✨

so this resource agent is out here managing Linux software RAID (MD) devices on a shared storage medium, and its whole main character job is making sure that non-clustered MD arrays are prohibited from starting cloned β€” because that would literally cause data corruption (e.g., on raid6 arrays) unless you force it (that's the force_clones parameter, we'll get there 🫢). but plot twist: clustered MD RAID layouts (see below, babe) get discovered and allowed to clone by default, so no need to set force_clones for those. slay.

it uses mdadm(8) to start, stop, and monitor the MD devices. iconic behavior, honestly.

the supported clustered (i.e., clonable active-active) arrays are linear, raid0, and clustered raid1/raid10 (i.e. mdadm(8) created with

--bitmap=clustered

). yup, that's the whole list, don't come for me 😭

Option: OCF_CHECK_LEVEL

when OCF_CHECK_LEVEL is set to any number greater than 0, the standard monitor operation (including probe) will check the array and attempt a recovery sequence to re-add devices if any failed device exists. by default, OCF_CHECK_LEVEL is unset, and this is disabled. so like... off by default, bestie. turn it on if you want the extra look-over πŸ‘‘


πŸŽ€ SUPPORTED PARAMETERS πŸŽ€

  • mdadm_conf β€” the MD RAID configuration file (e.g., /etc/mdadm.conf). this one is required, it's a string, and there's no default β€” you gotta bring your own, no shortcuts πŸ™ˆ
  • md_dev β€” the MD array block device to use (e.g., /dev/md0 or /dev/md/3). with shared access to the array's storage, this should preferably be a clustered raid1 or raid10 array created with --bitmap=clustered, assuming its resource will be cloned (i.e., active-active access). πŸ’«

one or more block devices to use, space separated. alternatively, set it to "auto" to manage all devices specified in mdadm_conf. be sure to disable auto-assembly for the resource-managed arrays! ⭐

required, string, no default.

  • force_stop β€” okay so if processes or kernel threads are using the array, it cannot be stopped. so we will try to stop those processes, first by sending TERM and then, if that doesn't help in seconds, using KILL. the lsof(8) program is required to get the list of array users. and of course, the kernel threads cannot be stopped this way (rude, but true πŸ’€). if the processes are critical for data integrity, then set this parameter to false β€” but note that in that case the stop operation will fail and the node will be fenced. so like, choose wisely bestie.

optional, boolean, default false.

  • wait_for_udev β€” wait until udevd creates a device in the start operation. on a normally loaded host this should happen quickly, but you may be unlucky 😭. if you are not using udev, set this to "no".

optional, boolean, default true.

  • force_clones β€” activating the same, non-clustered MD RAID array (i.e. single-host raid1/4/5/6/10) on multiple nodes at the same time will result in data corruption and thus is forbidden by default. periodt.

a safe example could be an (exotic) array that is only named identically across all nodes, but is in fact based on distinct (non-shared) storage. 🌈

⚠️ only set this to "true" if you know what you are doing! like, actually know. this is not a vibe-check situation, this is a data-integrity situation 🫢

optional, boolean, default false.


πŸ‘‘ SUPPORTED ACTIONS πŸ‘‘

this resource agent supports the following actions (operations):

  • start β€” starts the resource. suggested minimum timeout: 20s. ✨
  • stop β€” stops the resource. suggested minimum timeout: 20s.
  • monitor β€” performs a detailed status check. suggested minimum timeout: 20s. suggested interval: 10s. this is the one that's always watching, main character energy fr πŸ’…
  • validate-all β€” performs a validation of the resource configuration. suggested minimum timeout: 5s.
  • meta-data β€” retrieves resource agent metadata (internal use only). suggested minimum timeout: 5s.

πŸ¦‹ EXAMPLE CRM SHELL πŸ¦‹

the following is an example configuration for a mdraid resource using the crm(8) shell:

primitive p_mdraid ocf:heartbeat:mdraid \
  params \
    mdadm_conf=string \
    md_dev=string \
  op monitor depth="0" timeout="20s" interval="10s"

copy-paste girlies, this one's for you πŸ“


πŸ’œ EXAMPLE PCS πŸ’œ

the following is an example configuration for a mdraid resource using pcs(8)

pcs resource create p_mdraid ocf:heartbeat:mdraid \
  mdadm_conf=string \
  md_dev=string \
  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"

note the OCF_CHECK_LEVEL="0" in there β€” that's the pcs flavor, iykyk 😌


πŸ”₯ SEE ALSO πŸ”₯


🌟 AUTHOR 🌟

ClusterLabs contributors (see the resource agent source for information about individual authors). shoutout to every single one of them, absolute legends πŸ«ΆπŸ‘‘


and that's the tea, bestie β€” go forth and manage those MD arrays responsibly πŸ’…βœ¨

okay bye ily, this page was brought to you by resource-agents UNKNOWN, dated 10/01/2026 β€” no thoughts, just RAID πŸŒΈπŸŽ€πŸ¦‹

πŸ“¦ where this page comes from