<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 27, 2018 at 8:18 PM, Gionatan Danti via zfs-discuss <span dir="ltr"><<a href="mailto:zfs-discuss@list.zfsonlinux.org" target="_blank">zfs-discuss@list.zfsonlinux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
given a system with a proper, writeback-enabled RAID controller which can both create a classical array on some disks *and* passthrough some other disks, is it a good idea to place L2ARC and SLOG on the HW array?<br></blockquote><div><br></div><div>If you have write-caching enabled, why not just skip SLOG all together? If all your disks are hooked up to the same controller, all of your writes will be rendered asynchronous anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My reasoning is:<br>
- using CentOS I would like to avoid ZFS on root, so I need some sort of mirrored system partition (ie: MDRAID or HW array);<br></blockquote><div><br></div><div>Why? I have been running ZFS roon on CentOS for quite some years now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- an HW RAID1 mirror provide resiliency and very easy replacement of a failed disk (ie: disk replacement is completely transparent both for the OS and the L2ARC/SLOG);<br></blockquote><div><br></div><div>Why do you think it's easier to replace a failed disk in hardware RAID than using zfs replace?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- a writeback-enabled RAID card give very low write latency, which is ideal for SLOG; </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- data stay on SLOG for a short time only and are read on emergency recovery only, meaning the probability of an unrecoverable read error is very low;<br></blockquote><div><br></div><div>Are you using a different controller for your bulk data? If not, what do you think SLOG will get you that the writeback cache on the controller won't get you without it?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- by using SSD for the system disks, I can partition them for L2ARC use;<br>
- any failed/uncorrect L2ARC read will be trasparently redirected to the main pool;<br>
- the main pool has full ZFS protection against bit root and the likes.<br>
<br>
On the other hand, by using a software RAID1 array for the OS partition only, presenting the other SSD partitions directly to ZFS, I can stripe the L2ARC partition for added cache space (which is the solution I am commonly adopting). Moreover, I trust MDRAID way more the HW blackboxes.<br></blockquote><div><br></div><div></div></div></div><div class="gmail_extra">Disable writeback cache, let ZFS take care of the lot, and never look back.</div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div></div>