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