zfs_recovery=1, zdb, mounted pool?

[Xin Li]

On 8/14/16 21:46, Zaphod Beeblebrox wrote:
> On Sun, Aug 14, 2016 at 7:50 PM, Xin Li <delphij at delphij.net
> <mailto:delphij at delphij.net>> wrote:
> 
> 
> 
>     On 8/14/16 13:04, Zaphod Beeblebrox wrote:
>     > So... I found 319 of the errno 122 errors by running zdb.  My
>     question is
>     > this:
>     >
>     > Can I run with zfs_recovery=1 and have zdb fix these (which are
>     free space
>     > leaked errors) while the system is running?
> 
>     No.
> 
>     If I was you I would definitely do a full backup to a different place,
>     recreate the pool and restore from the backup.
> 
>     It's not safe to use your pool as-is, don't do it for everybody's sake.
> 
> 
>  So, then, do I start a big bug on this issue?  Is there a bug on this
> issue?  Seriously... it appears to have happened to multiple people.

I don't think so -- zfs_recovery is the last resort option that disables
certain assertions, which implies that your pool is already damaged
beyond repair (i.e. beyond the redundancy margin that ZFS have had built
in, e.g. multiple copies of metadata, RAID-Z, etc.), typically as a
result of RAM issues.

In theory it is possible to rebuild space map and recover the space, but
note that space map have sufficient redundancy that, if you have see
errors in it that can not be corrected by ZFS's self-healing, it's
highly likely that there are much more damage to the pool already.  If
you don't have a reproduction case for this one that can reliably
trigger a leak without hardware issue, I think it would be just a waste
of time to file a bug.

Cheers,

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