On Jul 1, 2019, at 8:26 AM, Valeri Galtsev <galt...@kicp.uchicago.edu> wrote:
>
> RAID function, which boils down to simple, short, easy to debug well program.
RAID firmware will be harder to debug than Linux software RAID, if only because
of easier-to-use tools.
Furthermore, MD RAID only had to be debugged once, rather that once per
company-and-product line as with hardware RAID.
I hope you’re not assuming that hardware RAID has no bugs. It’s basically a
dedicated CPU running dedicated software that’s difficult to upgrade.
> if kernel (big and buggy code) is panicked, current RAID operation will never
> be finished which leaves the mess.
When was the last time you had a kernel panic? And of those times, when was
the last time it happened because of something other than a hardware or driver
fault? If it wasn’t for all this hardware doing strange things, the kernel
would be a lot more stable. :)
You seem to be saying that hardware RAID can’t lose data. You’re ignoring the
RAID 5 write hole:
https://en.wikipedia.org/wiki/RAID#WRITE-HOLE
If you then bring up battery backups, now you’re adding cost to the system.
And then some ~3-5 years later, downtime to swap the battery, and more
downtime. And all of that just to work around the RAID write hole.
Copy-on-write filesystems like ZFS and btrfs avoid the write hole entirely, so
that the system can crash at any point, and the filesystem is always consistent.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
