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

Gordan Bobic gordan.bobic at gmail.com
Sun Apr 29 19:19:07 EDT 2018


On Mon, 30 Apr 2018, 00:06 Richard Elling via zfs-discuss, <
zfs-discuss at list.zfsonlinux.org> wrote:

>
> On Apr 29, 2018, at 3:16 PM, Richard Yao <ryao at gentoo.org> wrote:
> On Apr 29, 2018, at 6:11 PM, Richard Elling <
> richard.elling at richardelling.com> wrote:
>
>
> On Apr 29, 2018, at 12:48 PM, Richard Yao via zfs-discuss <
> zfs-discuss at list.zfsonlinux.org> wrote:
>
> On Apr 29, 2018, at 2:58 PM, Richard Yao via zfs-discuss <
> zfs-discuss at list.zfsonlinux.org> wrote:
>
> On Apr 29, 2018, at 2:50 PM, Edward Ned Harvey (zfsonlinux) via
> zfs-discuss <zfs-discuss at list.zfsonlinux.org> wrote:
>
> From: zfs-discuss <zfs-discuss-bounces at list.zfsonlinux.org> On Behalf
>
> Of Gandalf Corvotempesta via zfs-discuss
>
>
> This bitrot myth is totally nonsense today
>
>
> I have seen both cases - I've seen environments like Gandalf describes,
> where bitrot simply never occurs, and I've seen environments like Gordon,
> Steve, Richard, and Durval describe, where it occurs. I've also seen
> environments where if it occurs, it could result in millions of dollars
> lost, and environments where if it occurs, nobody cares.
>
>
> It certainly is related to the hardware, and related to the price of the
> hardware, but that's not a pure indicator. You can't just blindly assume
> expensive SAS hardware will not do it, nor can you assume cheap SATA disks
> will do it. It partly comes down to manufacturer specifics in specific
> models of disk and specific factories... It also comes down to climate in
> the datacenter, cable management within the system chassis (interference
> and cross-talk) and various other factors.
>
>
> There is nothing in the hardware to protect against this. A misdirected
> write (likely caused by vibration) could be detected if a read is done
> afterward, but that has two problems. The first is that nobody does it
> because it hurts performance. The second is that there is no telling where
> the write went without stopping the world and scrutinizing everything (for
> several hours) and trying to make sense of how to fix it, which nobody
> does. It is in no way practical.
>
>
> Just to add to my remark, this video demonstrates vibrations can cause
> misdirected IOs:
>
> https://youtu.be/tDacjrSCeq4
>
> In that example, the vibrations are caused by yelling, but vibrations can
> come from anywhere, including other drives.
>
>
> Actually, that video demonstrates how HDDs protect themselves from
> misdirected writes
> caused by vibration. It is this protection that shows itself as latency,
> because the disk must
> rotate again before the write can be successfully completed.
>
>
> It can protect itself on reads, but are you certain that they can always
> catch the issue on writes? I understand that they could (one would hope)
> read the sector marker right before writing, but if the vibration throws it
> off between the read and write, something gets clobbered.
>
>
> Yes. There are separate read and write heads, so the tracking can be
> proven during the write, even when on the same surface.
>

Right, so this would assume that read head is in front of the write head.
Read head reads the data that is about to get overwritten. Spacing between
heads would have to be no more than one sector which is a bit tight.

Placing heads the other way around would give you a free write-read-verify
feature, which is probably a lot more useful.

It all seems like a bit of an over-elaborate bodge for the sake of being
able to use a crap file system on top of traditional RAID, and still not
having most of the advantages of ZFS. Surely the solution to using a bad
system is to use a good system, not elaborate bodges that still aren't
anywhere nearly as good.

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


More information about the zfs-discuss mailing list