On Mon, Sep 28, 2015 at 5:11 AM, Andriy Gapon <[email protected]> wrote:
> On 11/08/2015 20:54, Matthew Ahrens wrote: > > On Fri, Aug 7, 2015 at 7:18 AM, Andriy Gapon <[email protected] > > <mailto:[email protected]>> wrote: > > > > Your proposal seems like a more flexible approach. One thing that > bothers me a > > little bit is that every consumer of the new lzc_receive would have > to duplicate > > the code for reading / interpreting the BEGIN record. > > > > Yes, but every consumer might want to interpret the BEGIN record a > different way > > (i.e. use the fromsnap name in different ways to determine the name of > the > > snapshot to create) > > > > Possible alternative is to not read the begin record in userland at > all and let > > the kernel driver do it. After all, the current lzc_receive just > passes the > > record down to the kernel without any interpretation. That would > require > > changing the ZFS_IOC_RECV interface, of course. > > > > But then you'd have to teach the kernel all possible ways that userland > might > > want to specify the name to receive based on the fromsnap name in the > BEGIN > > record. Today /sbin/zfs supports at least 4 ways of doing it: > > > > - specify full pool/fs@snap > > - specify pool/fs, get @snap from BEGIN > > - specify pool/fs -d, append /everything/but/the/poolname@snap from > BEGIN > > - specify pool/fs -e, get /last_elem@snap from BEGIN > > Indeed. So, you have me convinced. > > The only potentially unfortunate side effect is that struct drr_begin would > become a part of the API. We could try to make it opaque to libzfs_core > users, > though, by providing a function to read the record from a file descriptor > and > then providing a number of accessor functions to extract useful values > from the > record. But not sure if that approach is worth the trouble, it certainly > seems > a bit cumbersome. > > I'm attaching my current work-in-progress on implementing your suggestion > (as I > understood it, possibly incorrectly). 'lzc_receive_basic' is the best > name with > which I could come up, but it's probably not the best name. I had a > trouble > picking up a name that would be expressive (of the intent) or descriptive > (of > the behavior) enough while still being not very long. > > Your patch makes sense to me. The BEGIN record is part of the stream format so it doesn't seem additionally restrictive to make it part of the API. --matt
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
