ZFS vs hardware RAID [freebsd-questions Digest, Vol 760, Issue 6]

[John Johnstone]

On 1/4/2019 2:48 PM, Steve O'Hara-Smith wrote:
> On Fri, 4 Jan 2019 16:14:06 +0000
> Dave B via freebsd-questions <freebsd-questions at freebsd.org> wrote:
> 
>> Understood re what ZFS can do, much the same as high end hardware
>> controllers with their own embedded software (BIOS) then.
> 
> 	I have never seen a hardware raid with block checksums and
> automatic repair of silent corruption.

Maybe it happened but you never had the opportunity to know about it. 
Couldn't a controller have repaired it without you knowing about it? 
Generally speaking the functionality inside all hardware RAID 
controllers is proprietary.  By specs and descriptions you can know a 
lot about them but much of it isn't easily understood.  Corrections done 
by the controllers and disks can be inferred by retrieving the hardware 
statistics (smartmontools, vendor supplied utilities, LSI, HP, IBM etc) 
but it's not easily interpreted.

Don't want to contribute to starting a long debate about ZFS vs hardware 
RAID but I think it should be pointed out that hardware RAID design, as 
in that implemented in a HBA, has had something typically called patrol 
read for quite a long time.  The idea being that on an ongoing basis the 
RAID controller periodically on its own reads the disk to detect and 
correct problems via ECC and utilizes spare sectors.  This isn't 
identical to the process that ZFS uses but it does offer a significant 
level of protection.  The patrol read concept makes it less likely for 
any corruption to be undetected or "silent".

I think it's useful to remember too that SAN level functionality grew 
out of RAID HBA designs.  ZFS grew out of implementing SAN concepts in 
host-based software.  In my opinion, if you look in detail at RAID in 
hardware, both HBA and SAN, and ZFS, there are a lot more similarities 
that most people recognize.  I'm not saying ZFS doesn't have advantages 
but in a lot of cases they aren't looked at realistically.

-
John J.