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

Gordan Bobic gordan.bobic at gmail.com
Sun Apr 29 05:54:32 EDT 2018


On Sun, 29 Apr 2018, 10:40 Gandalf Corvotempesta, <
gandalf.corvotempesta at gmail.com> 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.
>

Funny. I saw three instances in the past week. Underlying RAID passes back
data as good, ZFS fails the checksum on the block. Enterprise grade servers
with ECC memory. Non-transient errors.

That's out of 30 servers I had to migrate for a client last week, and only
between 30 and 50TB of data in total. I expect worse to come (orders of
magnitude more data to go).



> 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
>


Meanwhile, in the real world...
Also - nobody uses SAS storage for petabyte scale storage in the commercial
(non government funded) world.

>
> 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
>

Rsync by default only compares metadata, not full rolling data checksums.
If you are reading 100% of the data on both ends every time, the chances
are that it's not much cheaper than just sending it all anyway, unless it's
over a WAN. Certainly not practical with many terabytes in any case.


> So, i don't think that bitrot protection is something useful today and you
> always have backups for this rare corner case
>

Awesome for you, I guess you don't need ZFS in your magical environment.


> 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
>

This is diametrically opposed to my experience.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20180429/66713068/attachment.html>


More information about the zfs-discuss mailing list