Hello list, We applied this commit to our local repo, had to massage it a little bit. Most likely we are missing previous features. In particular, how snapshots are iterated, and bqueue.c
This of course means that our tests are a little suspect already. But perhaps those who know this commit better, might be able to tell us where we went wrong. The commit for us is: https://github.com/openzfsonosx/zfs/commit/fe992d8377c6c68d1f16bee7ec514f01602fb3fa Branch with it merged in: https://github.com/openzfsonosx/zfs/tree/upstream-20150909 Issue 1: We had issues when testing this, if the snapshot is in the pool (root) dataset. Ie, if snapshot name does not have a "/" in it. # zfs send -vt "1-b409231ef-b0-789c636064000310a500c4ec50360710e72765a526973030f41840d460c8a7a515a79630c001489e0d493ea9b224b518247178170736fd25f9e9a599290c0c89fae50ab2e59cc1c8f29c60f9bcc4dc540606277f7f5f878c4cb01d007e0f13be" | zstreamdump resume token contents: nvlist version: 0 object = 0x308c offset = 0x0 bytes = 0x8bac300 toguid = 0x5309771d20772f61 toname = BOOM@hi cannot resume send: 'BOOM@hi' is no longer the same snapshot used in the initial send Which comes down to "BOOM@hi" being passed to "guid_to_name()", and the first while ((cp = strrchr(pname, '/')) != NULL) { fails so we return ENOENT. I have looked at today's IllumOS guid_to_name() as well as the patch, but I still fail to see how it is supposed to handle the root's snapshot. Unless it is designed to not work with pool's dataset, if so, my bad :) Issue 2: We can find some corruption, that appears to be sections of zero-bytes. As can be seen here: https://github.com/openzfsonosx/zfs/commit/fe992d8377c6c68d1f16bee7ec514f01602fb3fa#commitcomment-13481065 -- Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)90-5578-8500 (work) Shibuya-ku, Tokyo | +81 (0)80-2090-5800 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
