New ZFSv28 patchset for 8-STABLE: Kernel Panic
Jean-Yves Avenard
jyavenard at gmail.com
Tue Dec 28 17:39:32 UTC 2010
On 29 December 2010 03:15, Jean-Yves Avenard <jyavenard at gmail.com> wrote:
> # zpool import
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 15.11r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 15.94r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 16.57r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 16.95r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 32.19r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 32.72r 0.00u 0.03s 0% 2556k
> load: 0.00 cmd: zpool 405 [spa_namespace_lock] 40.13r 0.00u 0.03s 0% 2556k
>
> ah ah !
> it's not the separate log that make zpool crash, it's the cache !
>
> Having the cache in prevent from importing the pool again....
>
> rebooting: same deal... can't access the pool any longer !
>
> Hopefully this is enough hint for someone to track done the bug ...
>
More details as I was crazy enough to try various things.
The problem of zpool being stuck in spa_namespace_lock, only occurs if
you are using both the cache and the log at the same time.
Use one or the other : then there's no issue
But the instant you add both log and cache to the pool, it becomes unusable.
Now, I haven't tried using cache and log from a different disk. The
motherboard on the server has 8 SATA ports, and I have no free port to
add another disk. So my only option to have both a log and cache
device in my zfs pool, is to use two slices on the same disk.
Hope this helps..
Jean-Yves
More information about the freebsd-stable
mailing list