NixOS: mdadm & mdcheck

Development
1

Hey all. I’ve migrated a host from a Ubuntu system configuration into a NixOS configuration, and along the way I noticed that a typical behavior in a Ubuntu system was missing – my software raid devices weren’t being scrubbed on a regular monthly basis to check for errors.

I created a NixOS module to address this (NixOS module to add mdcheck capabilities, which automatically scrubs swraid md devices on a fixed schedule; eventually I'd like to upstream this to nixpkgs but just shoved it here for now... · GitHub), but before I made an attempt to put this into a nixpkgs PR I had a few general questions that I thought would be better discussed here.

  • I’ve named the configuration added hardware.raid.swraid.monitor – is this a good naming scheme?

  • enable defaults to false – this maintains compatibility with existing NixOS systems, but, has some risks of being an unsafe configuration since regular raid scrubbing is a somewhat standard safety practice. Should this be false?

  • I removed some existing systemd units that are packaged by the mdadm package, but aren’t usable because they don’t subst in the right mdcheck/mdadm paths, and instead recreated the units via systemd.timers and systemd.services to allow configurability. Is this a good direction, or, would it be better to use the upstream unit files and tweak them?

  • This doesn’t run the mdmonitor systemd service which has a couple of functionalities; (a) it emails or runs a program on a device event, (b) it swaps spare devices between raid arrays if appropriate on the event of a failure. I didn’t want to include it because getting the functionality (b) requires enabling the functionality (a), which would require explicit configuration for “what to do”. Is leaving this out pretty reasonable? It could be enabled pretty easily by another module.

  • Aside from making the mdadm package changes by an overlay, is the rest of this somewhat appropriate to include in a nixpkgs PR? Any thoughts, concerns?

2 Likes
2

It’s probably better to just open the PR and allow for this discussion there.

1 Like
3

When you do open the PR, please ping me in there (same id as here) as I have a local module that might be of interest.

4

Alright, I’ve opened a PR and can take the discussion over there. Thanks.

1 Like