<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 23, 2016, at 7:36 AM, Chris Siebenmann <<a href="mailto:cks@cs.toronto.edu" class="">cks@cs.toronto.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>The sd.conf whitelist also requires a reboot to activate if you need<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>to add a new entry, as far as I know.<br class=""><br class=""> (Nor do I know what happens if you have some 512n disks and<br class=""> some 512e disks, both correctly recognized and in different<br class=""> pools, and now you need to replace a 512n disk with a spare 512e<br class=""> disk so you change sd.conf to claim that all of the 512e disks<br class=""> are 512n. I'd like to think that ZFS will carry on as normal,<br class=""> but I'm not sure. This makes it somewhat dangerous to change<br class=""> sd.conf on a live system.)<br class=""></blockquote><br class="">There are two cases if we don't use the remedy (whitelist in illumos<br class="">or -o ashift in ZoL) here:<br class="">a): 512n <---> 512e. This replacement should work *in theory* if the<br class="">lie works *correctly*.<br class=""></blockquote><br class=""> This will not work without the sd.conf workaround in Illumos.<br class=""><br class=""> All 512e disks that I know of correctly report their actual physical<br class="">disk size to Illumos (and to Linux/ZoL). When a disk reports a 4K<br class="">physical sector size, ZFS will refuse to allow it into an ashift=9<br class="">vdev *regardless* of the fact that it is 512e and will accept reads<br class="">and writes in 512-byte sectors.<br class=""><br class=""> In Illumos, you can use sd.conf to lie to the system and claim that<br class="">this is not a 512e but a 512n disk (ie, it has a 512 byte physical<br class="">sector size). I don't believe there's an equivalent on ZoL, but I<br class="">haven't looked.<br class=""><br class=""> This absolute insistence on ZFS's part is what makes ashift=9 vdevs so<br class="">dangerous today, because you cannot replace existing 512n disks in them<br class="">with 512e disks without (significant) hackery.<br class=""><br class="">(Perhaps I'm misunderstanding what people mean by '512e' here; I've<br class="">been assuming it means a disk which reports 512 byte logical sectors and<br class="">4k physical sectors. Such disks are what you commonly get today.)<br class=""></div></div></blockquote><div><br class=""></div><div>Yes. 512e means:</div><div> un_phy_blocksize = 4096 (or 8192)</div><div> un_tgt_blocksize = 512</div><div>for disks that don't lie. Lying disks claim un_phy_blocksize = 512 when it isn't.</div><div><br class=""></div><div>At this point, before the discussion degenerates further, remember that George</div><div>covered this in detail at the OpenZFS conference and in his blog.</div><div><a href="http://blog.delphix.com/gwilson/2012/11/15/4k-sectors-and-zfs/" class="">http://blog.delphix.com/gwilson/2012/11/15/4k-sectors-and-zfs/</a></div><div><br class=""></div><div><a href="http://www.youtube.com/watch?v=TmH3iRLhZ-A&feature=youtu.be" class="">http://www.youtube.com/watch?v=TmH3iRLhZ-A&feature=youtu.be</a></div><div><br class=""></div><div><br class=""></div><div> -- richard</div></div><br class=""></body></html>