Port of ZFSOnLinux solution for illumos-gate issue #2663 to FreeBSD

[Richard Yao]

On 11/14/2012 06:47 PM, Steven Hartland wrote:
> 
> ----- Original Message ----- From: "Richard Yao" <ryao at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20121114/7626b492/attachment.sig>