On Sun, Apr 13, 2014 at 6:59 AM, Chapman Flack <[email protected]>wrote:
> Dear Mr. Ahrens, > > I discovered the idea of zfs bookmarks by accident when a google search > for something else turned up this: > > https://www.illumos.org/issues/4369 > > Cool idea! I was just looking a little more closely and I had a few > questions (or possibly suggestions, depending on the answers to the > questions :): > > 1. In Issue 4369, it says "from the new manpage: > zfs bookmark [-r] snapshot bookmark" but when I check the manpage itself > http://src.illumos.org/source/xref/illumos-gate/usr/src/man/man1m/zfs.1m > it doesn't mention any -r option. Neither does zfs_main.c accept one: > > http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/zfs/zfs_main.c#6621 > > Was the -r an early idea that got decided against later? > That's right -- not so much that we decided against it, as didn't have time to implement it. > > 2. I see that a bookmark is accepted only in the single-dataset > form of zfs send, not the form that allows -R, -I, etc. Was there > a deep technical reason why that couldn't be supported, or just > low time / low interest? > There's no deep reason -- we just didn't have time and didn't need it for our use case. It would be great to see an extension to this to support -R, -I, etc. The issue is that -R uses an older style of zfs send kernel interface (ioctl) that we didn't want to mess with. > > My backup system currently makes significant use of -R and -I, so > the attraction of being able to replace snapshots with bookmarks > and reclaim the snapshot space wouldn't be available to me. :( > > 3. In a similar vein, is it possible to set and get user properties > on a bookmark? Again, my system keeps state notes in user properties > of snapshots that have been replicated, so the usefulness of bookmarks > would be reduced if the same notes could not be kept there. > Hm, no that isn't supported. Bookmarks are not implemented as datasets, so we'd have to invent another mechanism for this, but I don't imagine it would be that difficult. > > 4. Holds? (My system puts a hold with a known tag on any snapshot > that will still be needed as a base for the next -I ... it might be > nice if bookmarks could have holds too ... and therefore a userrefs > property into the bargain). > Nope, no holds either. But there is little need to ever delete bookmarks. It sounds like user properties would suffice for your use case. > > Finally, an (almost) unrelated question: the reason issue 4369 came > up in my google search was because of 4368, zfs send filesystems from > readonly pools. I'm very glad that's added. What I was searching for > was very closely related to that: zfs diff where the second arg isn't > a snapshot (which currently fails on a readonly pool because it tries > to create a snapshot under the hood). Will that work after 4368 too? > Obviously that would be very useful in forensics. > No, that won't work. It would require a bit more doing than fixing the zfs send (which can simply not do the hold/rele). > > I notice in the code changes for 4368 that that dataset on the > readonly pool "may have a ZIL, which must be ignored." I assume that > might also apply in the diff case.... Would it be worth making a note > in the manual that a send or diff in that case might not reflect some > of the most recent transactions? (I guess it would be more ideal if > there could be some way to interpret and include the ZIL in those cases - > it would be more in the ZFS style of things doing pretty much what you > think they will.) > Indeed; readonly pools are a bit of a corner case, typically only used for recovery. > > Or, should there be some option on zpool import or zfs mount that > forces discarding the ZIL, so if I have inspected or copied something > using diff or send while the pool was readonly, meaning I saw it in a > state with none of the ZIL applied, if I later do reimport it read-write > I can use that option to ensure it really is in the same state that > I saw with send or diff, and doesn't have other changes I never saw? > We should probably start by adding a warning to the documentation (e.g. zpool manpage), saying that readonly pools ignore their intent logs, and the readonly pool feature is generally for testing and recovery; there are still some kinks to be ironed out. This would be a great are for a knowledgable user such as yourself to contribute! I could also also imagine a flag to "zpool import" to discard the intent log, as you mentioned. If you have a separate log device, a workaround you could try removing or zeroing out the log device. --matt > > Thanks for any thoughts. > > Regards, > Chapman Flack >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
