-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-28 17:32, sdm wrote:
On 12/23/2016 05:19 PM, Carlos E. R. wrote:
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 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.
Thus software raid is are reliable as motherboard raid, at least, and both are considered production ready. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhj6rQACgkQja8UbcUWM1woNAD+NcFPCImj7sfTNaXkfZvttQfX VwjRaMXP79UElKj4N7cA/jDzXfRGWyCQwwGZlTcQcZc9z9HTe15la271BUdWVTcy =dvxb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org