Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Sep 2014 22:41:09 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 193875] [zfs] [panic] [reproducable] zfs/space_map.c: solaris assert: sm->sm_space + size <= sm->sm_size
Message-ID:  <bug-193875-8-kNlR3geudC@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-193875-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-193875-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193875

--- Comment #4 from Palle Girgensohn <girgen@FreeBSD.org> ---
(In reply to Xin LI from comment #3)
> Is this reproducable on a newly created pool?  It looks like you are using a
> pool formatted with old format and did not upgrade (DO NOT DO IT NOW!), and
> there may be existing damage with the space map -- in such case the only way
> to recover from the situation would be to copy all data off the pool,
> recreate it and restore the data.


Hi Xin Li, thanks for the reply!

I did not try a newly created pool, it is a large pool with data, one of two
redundant systems where we use zfs send | ssh | zfs recv to keep them in sync.
The other machine is still on 9.3, and we got this problem after updating one
system to 10.0. So, we cannot really upgrade just yet. Also, it shouln't
present such a big problem just running an old version...?

But as you say, there seems to something fishy with the pool, and maybe there
is nothing wrong with the kernel itself. 

Are you sure there are no other ways to fix this but to recreate the pool?
Thera are just Terabytes of data, it will take a week... :-/

is there no zdb magic or zpool export + scrub + zpool import ditto with
vfs.zfs.recover =1 that could help?

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193875-8-kNlR3geudC>