On 14/04/2015 21:30, Matthew Ahrens wrote: > First off, a million thanks for writing tests! I would love to see whatever > you > come up with become part of the test suite. > > Your analysis is correct. A fix for this was approved last year, I don't know > why it has not been integrated yet. I guess I'll do it myself. > > https://reviews.csiden.org/r/143/
Thanks a lot! This seems like a rather serious problem, because in my environment any filesystem that gets a bookmark just "disappears", it's not possible to perform any operation on it. > On Mon, Apr 13, 2015 at 11:01 PM, Andriy Gapon <[email protected] > <mailto:[email protected]>> wrote: > > 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] <mailto:[email protected]> > http://lists.open-zfs.org/mailman/listinfo/developer > > -- Andriy Gapon _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
