Date: Wed, 14 Nov 2012 19:35:35 -0500 From: Richard Yao <ryao@gentoo.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org, Eitan Adler <eadler@freebsd.org> Subject: Re: Port of ZFSOnLinux solution for illumos-gate issue #2663 to FreeBSD Message-ID: <50A438D7.2030607@gentoo.org> In-Reply-To: <098A2B6F89484CF1829EED7B9822DDD0@multiplay.co.uk> References: <50A329A4.9090304@gentoo.org> <3AD8FAE474C24860B57C75DEBE431126@multiplay.co.uk> <50A42490.90103@gentoo.org> <098A2B6F89484CF1829EED7B9822DDD0@multiplay.co.uk>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 11/14/2012 06:47 PM, Steven Hartland wrote: > > ----- Original Message ----- From: "Richard Yao" <ryao@gentoo.org> >> With that said, the orignal patch permitted ashift=17, but that was >> shown to permit pool corruption: >> >> https://github.com/zfsonlinux/zfs/issues/425 >> >> As far as I know, ashift=13 is the highest value permitted on both Linux >> and FreeBSD. The code can operate with higher values, but I do not >> recommend them. > > Interesting I'll have a play with that there may be other edge cases I'm > not aware of thanks for the heads up. > My understanding of it is that badly designed hardware does not obey barriers correctly. The uberblock history was intended to workaround this by keeping readily accessible records of older transactions that can be used in the event that newer transactions failed to complete due to bad hardware. Increasing ashift will reduce the uberblock history size because the total space in each label for the uberblock history is 128 KB and the entries are padded to 2^ashift. If ashift is increased to the point where completed transactions are no longer in the history, pool corruption will occur in the event of sudden power loss. Hardware that properly respects barriers should be fine with ashift=16 because the previous entry will always be okay, but substandard hardware is not. So far, ashift=13 is the highest value that has been observed to be safe. There were some rather useful things about this written on the Open Solaris mailing list, but unfortunately, I did not keep a list of links for use as references. The following provides a partial description of what I just described: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html Note that I consider my understanding of this issue to be incomplete, so please do not let my description of what I understand the issue to be prevent you from doing your own research. Yours truly, Richard Yao [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQpDjZAAoJECDuEZm+6ExkBWkP/jrREtDxbYoAwf3jH0o5UCvJ mTRxDze2Qcu+aQaAaveytRtQSCloFrUHtN5Y3GvYznQ31TNRfc9zE8QZl6tofATM Qy8/Lla0kUvpOI6sve7VbptMXjKNoBTrIrWOqQuaX7or04pWl34e0qcWPdGEuxj3 BG1zBlNKtXlBHgc5xWey3Vjm/Z6L+5ihtu6UXvTIrvYz2tQu5E9E/AkrMnqy/OQ8 PNAIILOwiu9jGaEDzic+0FS6HG1FOMlSfEI1/jT8ctFXFkBse7Wi2bGGNzzYwkAy AUH9I8QGs7nuZlBCwVc65wiKS+/CJ2kQWczKzTH26BzZljQMPIraneSYtJhUfmyF nB1Cj1fMYjKJAybjVXgSPxxXqnv8QhQelmE9n+xW3K6C8ZIq126UQHaU2JJGqZwx 2eqFyGykbuhvUH8f/eAzEnZUQ75BNWMfJ3yJ5sOoTlqXt31cGy5f84yAZBGPZEAU WTLlAlVp3/6/r76By8PE1QJUL5dgyZg92ARHqn6iuAGC09NpeCH+pKiTrFv/J9nF ncus5BCkbxAyoKMsfR2r3zy+z4Rn7lI3Tr5Y9oPSUKHufeJNnm1oadHYF+htLUQ2 MqBkeOKspnAcwXMpCUu6S0bciUva9+FKW9NgtMTKUAYdqUMXa731qq97UMQgaj9r jC94YtWFlOKzMgOIJ4mQ =g35k -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A438D7.2030607>