Il giorno gio 2 apr 2020 alle ore 23:23 Zygo Blaxell <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx> ha scritto: > mdadm raid5/6 has no protection against the kinds of silent data > corruption that btrfs can detect. If the drive has a write error and > reports it to the host, mdadm will eject the entire disk from the array, > and a resync is required to put it back into the array (correcting the > error in the process). If the drive silently drops a write or the data That's not true. mdadm has a lot of logic of retries/wait and different "reactions" on what is happening. You can have spare blocks to use just in case, to avoid to kick the entire drive just by one bad block. It has a write journal log, to avoid RAID5/6 write hole (since years, but people keep saying there's no way to avoid it on mdadm...) Also, the greatest thing to me, Neil Brown did an incredible job constantly (year by year) improving the logic of mdadm (tools and kernel) to make it more robust against users mistakes and protective/proactive on failing setup/operations emerging from reports on mailig list. Until I read the mdadm mailing list, the flow was: user complains for software/hardware problem, after a while Neil commit to avoid the same problem in the future. Very costructive and useful way to manage the project. A few times I was saved by the tools warning: "you're doing a stupid thing, that could loose your date. But if you are sure, you can use --force". Or the kernel complaining about: "I'm not going to assemble this. Use --force if you're sure". On BTRFS, Qu is doing the same great job. Lots of patches to address users problems. Kudos to Qu!
