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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10E57287115B01ACEEE4A2FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/2012 06:47 PM, Steven Hartland wrote: >=20 > ----- Original Message ----- From: "Richard Yao" <ryao@gentoo.org> >> With that said, the orignal patch permitted ashift=3D17, but that was >> shown to permit pool corruption: >> >> https://github.com/zfsonlinux/zfs/issues/425 >> >> As far as I know, ashift=3D13 is the highest value permitted on both L= inux >> and FreeBSD. The code can operate with higher values, but I do not >> recommend them. >=20 > Interesting I'll have a play with that there may be other edge cases I'= m > not aware of thanks for the heads up. >=20 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=3D16 because the previous entry will always be okay, but substandard hardware is not. So far, ashift=3D13 is the highest value that has been observed t= o 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.h= tml 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 --------------enig10E57287115B01ACEEE4A2FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----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----- --------------enig10E57287115B01ACEEE4A2FB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A438D7.2030607>