[zfs-discuss] L2ARC and SLOG on HW RAID with writeback cache

Richard Yao ryao at gentoo.org
Sun Apr 29 09:28:14 EDT 2018



>> On Apr 29, 2018, at 5:39 AM, Gandalf Corvotempesta via zfs-discuss <zfs-discuss at list.zfsonlinux.org> wrote:
>> 
>> Il ven 27 apr 2018, 21:29 Gordan Bobic via zfs-discuss <zfs-discuss at list.zfsonlinux.org> ha scritto:
>> Using hardware RAID might seem appealing but you are going to regret it the first moment you get bitten by bit rot that the hardware RAID didn't protect you from.
> 
> 
> This bitrot myth is totally nonsense today
> In last 15 years i've replaced thousands of disk on hundreds or servers, had multiple catastrophic failures (due to hw raid) but never ever seen a single bit rot. Never.
> 
> Probably bitrot was common with disks coming from a decade ago, but current disks (particularry with SAS interface) doesn't soffer bit rot too much (if at all) and SAS is able to perform the check automatically thank to T10 extension

I have seen RAID 1 randomly serve the wrong information because one of the copies was wrong. There was nothing to “perform the check”. A misdirected write will happily cause the wrong data to be present. Even if you are lucky and the sector(s) that get clobbered are clobbered sin such a way that it fails internal ECC, the sectors where the data was supposed to go still contain the wrong data.

> And Yes, i always check our file checksums, during the backup phase with rsync and during the backup monthly check where we perform a total md5 check on all backup files. 
> If rsync doesn't transfer a file, it means that both checksum (source and destinations) are identical and the only way to calculate a checksum is by reading both files in both server, thus no bitrot

Checking file checksums is great, but if your filesystem is blown apart from bad metadata, your file checksums checks are not going to mean anything.

By the way, there is a TOCTOU race with manual file checksums. You could generate a checksum for bad data or it could get corrupted after your check. Of course, this assumes that your filesystem has not been blown apart by a misdirected write.

> So, i don't think that bitrot protection is something useful today and you always have backups for this rare corner case
> 
> ZFS is much more useful in resilvering only used space and not the whole disks or for native compression and SSD cache
> 
> The raid part doesn't have any real advantage vs mdadm (Yes, i agree, avoid hw raid at any cost, but for other reasons, including a huge vendor lock-in, not for bitrot). 
> Honestly, mdadm is much more flexible. Using it everywhere from the Dinosaurs era without any single issue even by mixing cheap desktop drives with reallocated sectors (no TLER) , SSD and enterprise SAS in a single array

You really ought to read this:

http://open-zfs.org/wiki/Hardware#Hardware_RAID_controllers

Most of the criticisms apply to MDADM too.
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20180429/6bfc79ff/attachment-0001.html>


More information about the zfs-discuss mailing list