RAID Part 1: RAID can fail and lead to data loss
So? your point being...? My point is that mdadm does nothing for the write hole problem, and
On 12/23/2016 05:19 PM, Carlos E. R. wrote: people end up losing data because of it on unclean shutdowns. The video I linked to explains it, here again: https://youtu.be/hquOIFJU3og?t=1300 "One more option to avoid a write hole is to use a ZFS which is a hybrid of a filesystem and a RAID. ZFS uses "copy-on-write" to provide write atomicity. However, this technology requires a special type of RAID (RAID-Z) which cannot be reduced to a combination of common RAID types (RAID 0, RAID 1, or RAID 5)." - http://www.raid-recovery-guide.com/raid5-write-hole.aspx "Yes, unfortunately btrfs RAID5/6 still suffers from the write hole (10/2015). The one missing piece, from a reliability point of view, is that it is still vulnerable to the parity RAID "write hole", where a partial write as a result of a power failure may result in inconsistent parity data." - http://superuser.com/questions/701111/is-btrfs-vulnerable-to-raid-write-hole... Write hole is behaviour mdadm can't get around and it does the best it can considering the implementation. btrfs and write atomicity still appears to be a work in progress. OP's problem most likely isn't that btrfs is the culprit. Sounds more like mdadm and an unclean shutdown (power loss). If he can't afford a hardware RAID controller (A real one, not a $30 one) and ECC memory, then if it were me, I would opt for btrfs built-in software RAID 1 over mdadm RAID 1+btrfs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org