On 14/04/2015 08:04, Andriy Gapon wrote:
> So, I pass the following bookmarks nvlist to lzc_bookmark():
> {
> "pool/fs#bookmark": "pool/fs@snap",
> "pool/fs#another_bookmark": "pool/fs@snap"
> }
>
> That is, I am trying to create in one go two valid bookmarks that point to the
> same snapshot.
>
> This results in the following panic:
> assert: dsl_dataset_hold(dp, fnvpair_value_string(pair), ((char *)__func__),
> &snapds) == 0 (0x2 == 0x0), file: .../dsl_bookmark.c, line: ...
>
> A stack trace:
> panic()
> assfail3()
> dsl_bookmark_create_sync()
> dsl_sync_task_sync()
> dsl_pool_sync()
> spa_sync()
> txg_sync_thread()
>
> The panic confuses me a lot, because I couldn't figure out how
> dsl_dataset_hold
> could return ENOENT. I only have a guess: I think that the way of how
> dsl_dataset_zapify() works might cause this.
After a debugging session I think that I see a problem. It's not in the
"zapification" as I guessed, but the "zapification" is a trigger.
dsl_dataset_hold_obj() has a check for the large blocks support and that check
has a small but quite nasty bug. The check leaks an error code in the case the
support has not been enabled for a dataset:
if (doi.doi_type == DMU_OTN_ZAP_METADATA) {
err = zap_contains(mos, dsobj, DS_FIELD_LARGE_BLOCKS);
if (err == 0)
ds->ds_large_blocks = B_TRUE;
else
ASSERT3U(err, ==, ENOENT);
}
This ENOENT causes dsl_dataset_hold_obj() to fail.
> Additional note: the panic happens on FreeBSD, but I couldn't reproduce it on
> Linux.
Seems like ZoL hasn't imported the large blocks support and so it doesn't have
the bug.
--
Andriy Gapon
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
