step to reproduce :
build a simple2-disks raid1 with mdadm
remove on of the 2 disks
mdadm mark the array as inactive
(we could stop and re-assemble the array manually, but the point of this bug report is that debian shouldassemble such array at boot, and then send a warning email)
--- /etc/default/mdadm
AUTOCHECK=true
AUTOSCAN=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false
10474496 blocks super 1.2
unused devices: <none>
--- /proc/partitions:
major minor #blocks name
254 0 20971520 vda
254 1 19970048 vda1
254 2 1 vda2
254 5 998400 vda5
254 16 10485760 vdb
254 17 10483712 vdb1
11 0 1048575 sr0
--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=987632k,nr_inodes=246908,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=201416k,mode=755,inode64)
/dev/vda1 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1923)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=201416k,nr_inodes=50354,mode=700,inode64)
--- initrd.img-6.1.0-30-amd64:
gzip: /boot/initrd.img-6.1.0-30-amd64: not in gzip format
cpio: premature end of archive
--- initrd's /conf/conf.d/md:
no conf/md file.
--- /proc/modules:
dm_mod 184320 0 - Live 0xffffffffc0790000
raid10 65536 0 - Live 0xffffffffc05e8000
raid456 180224 0 - Live 0xffffffffc05b1000
async_raid6_recov 24576 1 raid456, Live 0xffffffffc05aa000
async_memcpy 20480 2 raid456,async_raid6_recov, Live 0xffffffffc05a4000
async_pq 20480 2 raid456,async_raid6_recov, Live 0xffffffffc059a000
async_xor 20480 3 raid456,async_raid6_recov,async_pq, Live 0xffffffffc0594000
async_tx 20480 5 raid456,async_raid6_recov,async_memcpy,async_pq,async_xor, Live 0xffffffffc046c000
raid6_pq 122880 3 raid456,async_raid6_recov,async_pq, Live 0xffffffffc0575000
libcrc32c 16384 1 raid456, Live 0xffffffffc0373000
raid1 53248 0 - Live 0xffffffffc052e000
raid0 24576 0 - Live 0xffffffffc02e2000
multipath 20480 0 - Live 0xffffffffc02b9000
linear 20480 0 - Live 0xffffffffc028f000
md_mod 192512 6 raid10,raid456,raid1,raid0,multipath,linear, Live 0xffffffffc04fe000
--- volume detail:
/dev/vda:
MBR Magic : aa55
Partition[0] : 39940096 sectors at 2048 (type 83)
Partition[1] : 1996802 sectors at 39944190 (type 05)
--
/dev/vda1 is not recognised by mdadm.
/dev/vda2:
MBR Magic : aa55
Partition[0] : 1996800 sectors at 2 (type 82)
--
/dev/vda5 is not recognised by mdadm.
/dev/vdb:
MBR Magic : aa55
Partition[0] : 20971519 sectors at 1 (type ee)
--
/dev/vdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 2ea7f497:85b26304:7c1f72bf:86855e42
Name : debian12-netinst:0 (local to host debian12-netinst)
Creation Time : Wed Jan 29 12:57:16 2025
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 20948992 sectors (9.99 GiB 10.73 GB)
Array Size : 10474496 KiB (9.99 GiB 10.73 GB)
Data Offset : 18432 sectors
Super Offset : 8 sectors
Unused Space : before=18280 sectors, after=0 sectors
State : clean
Device UUID : 6e1fbf2e:8282f505:7f1b0bb6:4c983339
Update Time : Wed Jan 29 12:59:33 2025
Bad Block Log : 512 entries available at offset 136 sectors
Checksum : c1714cee - correct
Events : 19
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
--
--- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.1.0-30-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro md-mod.start_dirty_degraded=1 quiet
--- grub2:
linux /boot/vmlinuz-6.1.0-30-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro md-mod.start_dirty_degraded=1 quiet
linux /boot/vmlinuz-6.1.0-30-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro md-mod.start_dirty_degraded=1 quiet
linux /boot/vmlinuz-6.1.0-30-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro single md-mod.start_dirty_degraded=1
linux /boot/vmlinuz-6.1.0-18-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro md-mod.start_dirty_degraded=1 quiet
linux /boot/vmlinuz-6.1.0-18-amd64 root=UUID=bdc1eeee-8e26-4a19-993f-03ec45058804 ro single md-mod.start_dirty_degraded=1
--- udev:
ii udev 252.33-1~deb12u1 amd64 /dev/ and hotplug management daemon
9d7dfcdc58fa54941f8d28f6094a7a5b /lib/udev/rules.d/01-md-raid-creating.rules
d767cffc82663d79b515f66ee8557fb4 /lib/udev/rules.d/63-md-raid-arrays.rules
b733421b507e8c6c87963f4bfb572ca5 /lib/udev/rules.d/64-md-raid-assembly.rules
ba1d376ca9b7364576f950d06ba18207 /lib/udev/rules.d/69-md-clustered-confirm-device.rules
134bbecc2a769a7c7d4ec930968ab162 /lib/udev/rules.d/99-systemd.rules
--- /dev:
brw-rw---- 1 root disk 9, 127 Jan 29 13:00 /dev/md127
/dev/disk/by-diskseq:
total 0
lrwxrwxrwx 1 root root 9 Jan 29 13:00 1 -> ../../vda
lrwxrwxrwx 1 root root 11 Jan 29 13:00 10 -> ../../loop4
lrwxrwxrwx 1 root root 11 Jan 29 13:00 11 -> ../../loop5
lrwxrwxrwx 1 root root 11 Jan 29 13:00 12 -> ../../loop6
lrwxrwxrwx 1 root root 11 Jan 29 13:00 13 -> ../../loop7
lrwxrwxrwx 1 root root 9 Jan 29 13:00 2 -> ../../vdb
lrwxrwxrwx 1 root root 9 Jan 29 13:00 5 -> ../../sr0
lrwxrwxrwx 1 root root 11 Jan 29 13:00 6 -> ../../loop0
lrwxrwxrwx 1 root root 11 Jan 29 13:00 7 -> ../../loop1
lrwxrwxrwx 1 root root 11 Jan 29 13:00 8 -> ../../loop2
lrwxrwxrwx 1 root root 11 Jan 29 13:00 9 -> ../../loop3
/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root root 9 Jan 29 13:00 ata-QEMU_DVD-ROM_QM00001 -> ../../sr0
/dev/disk/by-partuuid:
total 0
lrwxrwxrwx 1 root root 10 Jan 29 13:00 7bc103d1-01 -> ../../vda1
lrwxrwxrwx 1 root root 10 Jan 29 13:00 7bc103d1-02 -> ../../vda2
lrwxrwxrwx 1 root root 10 Jan 29 13:00 7bc103d1-05 -> ../../vda5
lrwxrwxrwx 1 root root 10 Jan 29 13:00 9ba910cf-554f-9047-9eb3-257d90476dbe -> ../../vdb1
/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root root 9 Jan 29 13:00 pci-0000:00:1f.2-ata-1 -> ../../sr0
lrwxrwxrwx 1 root root 9 Jan 29 13:00 pci-0000:00:1f.2-ata-1.0 -> ../../sr0
lrwxrwxrwx 1 root root 9 Jan 29 13:00 pci-0000:04:00.0 -> ../../vda
lrwxrwxrwx 1 root root 10 Jan 29 13:00 pci-0000:04:00.0-part1 -> ../../vda1
lrwxrwxrwx 1 root root 10 Jan 29 13:00 pci-0000:04:00.0-part2 -> ../../vda2
lrwxrwxrwx 1 root root 10 Jan 29 13:00 pci-0000:04:00.0-part5 -> ../../vda5
lrwxrwxrwx 1 root root 9 Jan 29 13:00 pci-0000:08:00.0 -> ../../vdb
lrwxrwxrwx 1 root root 10 Jan 29 13:00 pci-0000:08:00.0-part1 -> ../../vdb1
lrwxrwxrwx 1 root root 9 Jan 29 13:00 virtio-pci-0000:04:00.0 -> ../../vda
lrwxrwxrwx 1 root root 10 Jan 29 13:00 virtio-pci-0000:04:00.0-part1 -> ../../vda1
lrwxrwxrwx 1 root root 10 Jan 29 13:00 virtio-pci-0000:04:00.0-part2 -> ../../vda2
lrwxrwxrwx 1 root root 10 Jan 29 13:00 virtio-pci-0000:04:00.0-part5 -> ../../vda5
lrwxrwxrwx 1 root root 9 Jan 29 13:00 virtio-pci-0000:08:00.0 -> ../../vdb
lrwxrwxrwx 1 root root 10 Jan 29 13:00 virtio-pci-0000:08:00.0-part1 -> ../../vdb1
/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 10 Jan 29 13:00 bbbf6ad3-6147-42f6-a5e4-f54306c17658 -> ../../vda5
lrwxrwxrwx 1 root root 10 Jan 29 13:00 bdc1eeee-8e26-4a19-993f-03ec45058804 -> ../../vda1
Auto-generated on Wed, 29 Jan 2025 13:12:12 +0100 by mdadm bugscript
I finally managed to find a workaround (maybe a possible fix fix this bug ?) : edit /usr/share/initramfs-tools/scripts/local-block/mdadm L.42 : mdadm -q --assemble --scan *--no-degraded* || true remove the "--no-degraded" argument update-initramfs -u -k all update-grub after reboot, the raid array is active, despite degraded (missing 1 disk) Do you have any idea why there is this restriction ? any idea on how to make this workaround permanent (not erased with next mdadm package update) ? maybe we can find a way to change this in the source package ? thanks. Le 29/01/2025 à 13:18, Debian Bug Tracking System a écrit :
I've encountered the same issue, and my server stopped working. I have a
RAID1 array with LVM on top of it.
Here is the root cause and the proper way to fix it. I would also like to
ask Daniel Baumann for advice on how to proceed with a bug fix that I can
work on.
Root cause:
1. Debian's "mdadm" package contains initramfs hooks, initramfs scripts,
and udev rules. You can discover them with "dpkg -L mdadm".
2. The files we are interested in are
"/usr/share/initramfs-tools/scripts/local-block/mdadm" and
"/lib/udev/rules.d/64-md-raid-assembly.rules".
3. The initramfs hooks pack them into the initramfs image after the "mdadm"
package is installed, or after any kernel/initramfs updates.
4. By default, during the boot phase when initramfs is running, udev is
started as well.
5. udev receives events from the kernel and discovers block devices.
6. The "mdadm" udev rule in "/lib/udev/rules.d/64-md-raid-assembly.rules"
tries to assemble the array when block partitions with the
"linux_raid_member" filesystem type are discovered.
7. This rule calls "/sbin/mdadm --incremental --export $devnode --offroot
$env{DEVLINKS}". Incremental mode allows "mdadm" to start building the
array with the first disk and then add more disks as they are discovered.
The working array in my case had 2 disks. When 1 of them is missing,
"--incremental" builds the array, but does not make it active until the
second disk is present. This will never happen on a degraded array.
8. However, "mdadm" contains a "poor man's last-resort" approach that works
in combination with scripts from the "initramfs-tools-core" package. You
can inspect them with "dpkg -L initramfs-tools-core". This package installs
"/usr/share/initramfs-tools/init" and
"/usr/share/initramfs-tools/scripts/local".
9. "init" executes "local_device_setup", and "local_device_setup" is
defined in "scripts/local".
10. "local_device_setup" executes "local_block "${dev_id}"" in a while
loop, and "local_block" executes "scripts/local-block/mdadm". The loop has
a counter. Only after 2/3 of the "ROOTDELAY" time has elapsed, it executes
"mdadm -q --assemble --scan --no-degraded || true". Obviously, with
"--no-degraded", it fails if the array is in a degraded state.
11. After 2/3 of the "ROOTDELAY" time has elapsed, it executes "mdadm -q
--run /dev/md?*" once, and the array becomes active even in a degraded
state.
12. It does not help in my case because I get an active array, but LVM is
not assembled. To assemble it, we need either to do this manually via a
custom script or to trigger udev to discover block devices again. One of
those devices will be our RAID device, so udev will trigger the LVM udev
rule to activate it.
13. Unfortunately, "mdadm" does not handle this well and does not trigger
udev.
Quick fix:
1. Do not edit any content in "/lib/udev/rules.d/" or
"/usr/share/initramfs-tools/". These files will be overwritten by updates.
2. Custom scripts should be placed in "/etc/udev/rules.d/" and
"/etc/initramfs-tools/", respectively.
3. Copy the original "mdadm" script to "/etc/initramfs-tools/": "sudo cp
/usr/share/initramfs-tools/scripts/local-block/mdadm
/etc/initramfs-tools/scripts/local-block/mdadm"
4. Add the following 2 lines after "mdadm -q --assemble --scan --run":
udevadm trigger --action=add -s block || true
wait_for_udev 10
5. Rebuild initramfs: "sudo update-initramfs -u -k all"
6. Optionally, inspect its content with "unmkinitramfs".
Permanent fix. Daniel Baumann, please comment on this.
1. It looks like the logic in the "mdadm" initramfs scripts conflicts with
the "initramfs-tools-core" scripts.
2. "scripts/local-block/mdadm" contains code that removes the
"/run/count.mdadm.initrd" counter. Other lines of code trigger udev when
"/run/count.mdadm.initrd" is missing. This resets the counter to 0, so
technically, with this logic, arrays should be activated. However, this
never happens because "scripts/local" detects the removal and recreates the
file. That is why I have no idea why this logic with removal and udev
triggering exists.
3. Maybe it was just a mistake, or maybe there is some logic that I am not
familiar with. So I am asking for your advice. I can submit a merge request
with the fix described above. I have tested it.
Thank you in advance.
Earlier this year I've experienced this bug and had to investigate
its cause and remedy.
First Let me start with background, rationale and a rant about
epic fail of incremental assembly:
:::
RAID-1 is for reliability, availability and fault-tolerance.
Consider configuration where `/home` partition is on 3 HDDs, arranged
into mdRAID-1, with a hot spare. Once HDD dies/disappears, a (hot)
spare is immediately used to replace bad/missing disk and restore
200% data redundancy. That is what's expected from such array and
it is how things used to work on Debian few releases ago.
With introduction of "incremental assembly" in mdadm, *principle of
least surprise* is violated: on boot mdadm add disks to array using
`udev` handler and when (failed or disconnected) disk never appears,
system falls into emergency recovery shell instead of recovering
array automatically. (That's what hot spare is for!)
This is an epic disaster in mdadm behaviour for few reasons:
1) Emergency recovery mode starts early, before network and SSH
service. Hence instead of increased fault tolerance, we have
machine that needs console access because it is not bootable
normally, and even to experienced admin it is not terribly
obvious how to repair partially assembled RAID1 array with
missing disk. This is betrayal (of expectations) number one,
compromising availability that RAID-1 is meant to protect.
2) Hot spare is there so that (presumably sensitive) data could be
immediately replicated to second device, in order to protect
valuable data from eventual failure of the only remaining HDD.
Not using hot spare automatically is betrayal number two, because
delayed replication that requires admin interaction jeopardise
data recovery by delaying (actually not doing) recovery,
increasing odds of catastrophic data loss.
Frankly I'm shocked how badly mdadm handles recoverable failures
nowadays, and what tremendous regression that is from former correct
behaviour.
Remedy is not even documented and it is not clear how to revert to
former behaviour where RAID1 is automatically recovered using hot
spare HDD without compromising boot...
:::
The essence of this problem as I understand it, is that incremental
assembly happens (all available disks are discovered) but degraded
arrays are not *run*.
As workaround I've invoked `mdadm -q --run /dev/md?*` from
`/etc/initramfs-tools/scripts/local-premount/mdadm` as follows:
```
#!/bin/sh
PREREQ="mdadm"
prereqs() { echo "$PREREQ"; }
case $1 in prereqs) prereqs; exit 0;; esac
. /scripts/functions
## This is required to auto-rebuild degraded arrays with spares, instead of falling to emergency recovery mode.
## See https://bugs.debian.org/1094629 for details.
log_begin_msg "mdadm: Ensure that all arrays are running."
mdadm -q --run /dev/md?* || true
sleep 2
log_end_msg
```
Followed by
sudo chown -c root:root /etc/initramfs-tools/scripts/local-premount/mdadm
sudo chmod -c u+x /etc/initramfs-tools/scripts/local-premount/mdadm
sudo update-initramfs -u -k all
That fixed the problem nicely for me.
I had to use this workaround on several machines.
I've thoroughly tested that approach on few PCs by randomly
disconnecting disks and ensuring that machines remain bootable,
with automatic mdraid recovery from available spare.
I am not aware of any side effects of this approach.
---
Politics: a Trojan horse race.
-- Stanisław Jerzy Lec
Earlier this year I've experienced this bug and had to investigate
its cause and remedy.
First Let me start with background, rationale and a rant about
epic fail of incremental assembly:
:::
RAID-1 is for reliability, availability and fault-tolerance.
Consider configuration where `/home` partition is on 3 HDDs, arranged
into mdRAID-1, with a hot spare. Once HDD dies/disappears, a (hot)
spare is immediately used to replace bad/missing disk and restore
200% data redundancy. That is what's expected from such array and
it is how things used to work on Debian few releases ago.
With introduction of "incremental assembly" in mdadm, *principle of
least surprise* is violated: on boot mdadm add disks to array using
`udev` handler and when (failed or disconnected) disk never appears,
system falls into emergency recovery shell instead of recovering
array automatically. (That's what hot spare is for!)
This is an epic disaster in mdadm behaviour for few reasons:
1) Emergency recovery mode starts early, before network and SSH
service. Hence instead of increased fault tolerance, we have
machine that needs console access because it is not bootable
normally, and even to experienced admin it is not terribly
obvious how to repair partially assembled RAID1 array with
missing disk. This is betrayal (of expectations) number one,
compromising availability that RAID-1 is meant to protect.
2) Hot spare is there so that (presumably sensitive) data could be
immediately replicated to second device, in order to protect
valuable data from eventual failure of the only remaining HDD.
Not using hot spare automatically is betrayal number two, because
delayed replication that requires admin interaction jeopardise
data recovery by delaying (actually not doing) recovery,
increasing odds of catastrophic data loss.
Frankly I'm shocked how badly mdadm handles recoverable failures
nowadays, and what tremendous regression that is from former correct
behaviour.
Remedy is not even documented and it is not clear how to revert to
former behaviour where RAID1 is automatically recovered using hot
spare HDD without compromising boot...
:::
The essence of this problem as I understand it, is that incremental
assembly happens (all available disks are discovered) but degraded
arrays are not *run*.
As workaround I've invoked `mdadm -q --run /dev/md?*` from
`/etc/initramfs-tools/scripts/local-premount/mdadm` as follows:
```
#!/bin/sh
PREREQ="mdadm"
prereqs() { echo "$PREREQ"; }
case $1 in prereqs) prereqs; exit 0;; esac
. /scripts/functions
## This is required to auto-rebuild degraded arrays with spares, instead of falling to emergency recovery mode.
## See https://bugs.debian.org/1094629 for details.
log_begin_msg "mdadm: Ensure that all arrays are running."
mdadm -q --run /dev/md?* || true
sleep 2
log_end_msg
```
Followed by
sudo chown -c root:root /etc/initramfs-tools/scripts/local-premount/mdadm
sudo chmod -c u+x /etc/initramfs-tools/scripts/local-premount/mdadm
sudo update-initramfs -u -k all
That fixed the problem nicely for me.
I had to use this workaround on several machines.
I've thoroughly tested that approach on few PCs by randomly
disconnecting disks and ensuring that machines remain bootable,
with automatic mdraid recovery from available spare.
I am not aware of any side effects of this approach.
---
Politics: a Trojan horse race.
-- Stanisław Jerzy Lec
21.05.2026 12:15, Dmitry Smirnov wrote: this particular scenario. If you have 3 HDDs for RAD1, it's much better and reliable to use 3-way raid1 from the beginning, instead of 2-way raid1 + hot spare. This way you eliminate the thin ice in here: if one drive dies and you'll have just one copy left, the probability to encounter second failure (which is now fatal!) increases significantly, since during recovery, *whole* remaining drive has to be read, including areas which hasn't been touched for long, and where you might face some bad sectors. And recovering from *that* situation is significantly more difficult. When you've 3-way raid1, symmetrical, instead, everything works as it should be. And as a bonus, you have better read performance (but at a price of very slightly worse write performance). Also, none of the disasterous scenarious you outlined, wont occur. FWIW, /mjt
21.05.2026 12:15, Dmitry Smirnov wrote: this particular scenario. If you have 3 HDDs for RAD1, it's much better and reliable to use 3-way raid1 from the beginning, instead of 2-way raid1 + hot spare. This way you eliminate the thin ice in here: if one drive dies and you'll have just one copy left, the probability to encounter second failure (which is now fatal!) increases significantly, since during recovery, *whole* remaining drive has to be read, including areas which hasn't been touched for long, and where you might face some bad sectors. And recovering from *that* situation is significantly more difficult. When you've 3-way raid1, symmetrical, instead, everything works as it should be. And as a bonus, you have better read performance (but at a price of very slightly worse write performance). Also, none of the disasterous scenarious you outlined, wont occur. FWIW, /mjt
You mean something like "--level=1 --raid-devices=3" ? I did not know that mdadm supports such configuration. Excellent point, thanks.--- Freedom is lost gradually through uninterested, uninformed, uninvolved people.
You mean something like "--level=1 --raid-devices=3" ? I did not know that mdadm supports such configuration. Excellent point, thanks.--- Freedom is lost gradually through uninterested, uninformed, uninvolved people.
You mean something like "--level=1 --raid-devices=3" ? I did not know that mdadm supports such configuration. Excellent point, thanks.--- Freedom is lost gradually through uninterested, uninformed, uninvolved people.
In general, this recommended approach with --raid-devices=3 will work, but will fail during boot too. When 1 from 3 is lost the md array will fall to the degraded mode. чт, 21 мая 2026 г. в 14:19, Michael Tokarev <mjt@tls.msk.ru>:
In general, this recommended approach with --raid-devices=3 will work, but will fail during boot too. When 1 from 3 is lost the md array will fall to the degraded mode. чт, 21 мая 2026 г. в 14:19, Michael Tokarev <mjt@tls.msk.ru>: