Another update to my post: it took a week to try running
some ZDB walks on my pool, but they coredumped after a while.
However, I've also noticed some clues in my FMADM outputs
dating from 'zpool scrub' attempts. There are several sets
(one set per scrub) of similar error reports, differing only
On Mon, Dec 5, 2011 at 17:46, Jim Klimov jimkli...@cos.ru wrote:
So, in contrast with Nigel's optimistic theory that
metadata is anyway extra-redundant and should be
easily fixable, it seems that I do still have the
problem. It does not show itself in practice as of
yet, but is found by scrub
Well, I have an intermediate data point. One scrub run
completed without finding any newer errors (beside one
at the pool-level and two and the raidz2-level).
Zpool clear alone did not fix it, meaning that the
pool:metadata:0x0 was still reported as problematic,
but a second attempt at zpool
2011-12-02 18:25, Steve Gonczi пишет:
Hi Jim,
Try to run a zdb -b poolname ..
This should report any leaked or double allocated blocks.
(It may or may not run, it tends to run out of memory and crash on large
datasets)
I would be curious what zdb reports, and whether you are able to run it
On Fri, Dec 2, 2011 at 02:58, Jim Klimov jimkli...@cos.ru wrote:
My question still stands: is it possible to recover
from this error or somehow safely ignore it? ;)
I mean, without backing up data and recreating the
pool?
If the problem is in metadata but presumably the
pool still works,
