<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><span></span><br><blockquote type="cite"><span>On Apr 29, 2018, at 4:37 PM, Gionatan Danti <<a href="mailto:g.danti@assyoma.it">g.danti@assyoma.it</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Il 29-04-2018 21:48 Richard Yao via zfs-discuss ha scritto:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>There is nothing in the hardware to protect against this. A</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>misdirected write (likely caused by vibration) could be detected if a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>read is done afterward, but that has two problems. The first is that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>nobody does it because it hurts performance. The second is that there</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>is no telling where the write went without stopping the world and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>scrutinizing everything (for several hours) and trying to make sense</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>of how to fix it, which nobody does. It is in no way practical.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>T10 DIF/DIX *does* protect against misredicted writes: <a href="https://www.usenix.org/legacy/event/lsf07/tech/petersen.pdf">https://www.usenix.org/legacy/event/lsf07/tech/petersen.pdf</a></span><br></blockquote><blockquote type="cite"><span>However, it requires expensive SAS controllers, backplanes and disks.</span></blockquote><div><br></div>Despite claims to the contrary by Oracle, I do not see how T10 protects against misdirected writes:</div><div><br></div><div><a href="https://lwn.net/Articles/280023/">https://lwn.net/Articles/280023/</a></div><div><br></div><div>Every misdirected write affects at least two locations. There is the target location, which will have stale data. Then there is the clobbered location, which might have be readable with the wrong data or might be completely unreadable due to misalignment. Proper handling of misdirected writes requires handling both locations.</div><div><br></div><div>My read of T10 is that it will write a DIF tag containing a hash of the LBA. Then when the data is read, that hash is read and verified. If it is wrong, then a read error occurs. If it is correct, then the data is passed onward. A sector with stale data from a misdirected write will pass this check. This handles the clobbered data case.</div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">A feature of hard drives designed for old mainframes was that they would read after writing to verify that data at the correct location had been updated. This handles the stale data case.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">You need to handle both cases to protect against misdirected writes, but </span><span style="background-color: rgba(255, 255, 255, 0);">I read nothing about T10 that claims it requires a read after write to handle the stale data case. I also find nothing that talks about the loss in performance that implementing T10 would occur if it required that drives do a read after every write.</span></div><div><span></span><br><blockquote type="cite"><span>That said, I reiterate: my question about HW RAID was limited to SATA-based L2ARC/SLOG.</span><br></blockquote><blockquote type="cite"><span>Any thoughts on that?</span><br></blockquote><div><br></div>As always, I suggest giving the devices directly to ZFS. Having other things on the same device can limit the benefit of L2ARC and SLOG. If you want to share the disks for the main pool with a different filesystem for /, you can use partitions, but they should be aligned and you will need to set noop on the disk manually to avoid unnecessary overhead.</div><div><br></div><div>Another option is to put / on a zvol, have an initramfs import the pool and then mount / from the zvol. That is not very common, but I am told that Ubuntu/Debian users do it.</div><div><br><blockquote type="cite"><span></span></blockquote><blockquote type="cite"><span>Thanks.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>Danti Gionatan</span><br></blockquote><blockquote type="cite"><span>Supporto Tecnico</span><br></blockquote><blockquote type="cite"><span>Assyoma S.r.l. - <a href="http://www.assyoma.it">www.assyoma.it</a></span><br></blockquote><blockquote type="cite"><span>email: <a href="mailto:g.danti@assyoma.it">g.danti@assyoma.it</a> - <a href="mailto:info@assyoma.it">info@assyoma.it</a></span><br></blockquote><blockquote type="cite"><span>GPG public key ID: FF5F32A8</span><br></blockquote></div></body></html>