On Fri, Apr 24, 2015 at 4:38 AM, Andriy Gapon <[email protected]>
wrote:
> On 24/04/2015 02:25, Matthew Ahrens wrote:
> > I think that's a bug / not-fully-implemented-feature. "zfs receive -F"
> should
> > be allowed to destroy whatever it takes to do the receive that you
> requested.
> > (Also the manpage should be updated to reflect this.)
>
>
> To sum up what we've been discussing: does the following patch look like a
> reasonable change:
>
> --- dmu_send.c
> +++ dmu_send.c
> @@ -982,10 +982,12 @@ recv_begin_check_existing_impl()
>
> dsl_dataset_rele(snap, FTAG);
> } else {
> - /* if full, most recent snapshot must be $ORIGIN */
> - if (ds->ds_phys->ds_prev_snap_txg >= TXG_INITIAL)
> - return (SET_ERROR(ENODEV));
> - drba->drba_snapobj = ds->ds_phys->ds_prev_snap_obj;
> + /* if full, then must be forced */
> + if (!drba->drba_cookie->drc_force)
> + return (SET_ERROR(EEXIST));
> + /* start from $ORIGIN@$ORIGIN, if supported */
> + drba->drba_snapobj = dp->dp_origin_snap != NULL ?
> + dp->dp_origin_snap->ds_object : 0;
> }
>
> return (0);
>
> I do not have a strong opinion about the return code. EEXIST makes sense
> to me,
> but possibly some other code like ENODEV or ETXTBUSY makes even more sense.
>
That looks good to me, assuming the rest of the code handles it correctly
(destroying the unneeded snaps - even on pools from before $ORIGIN). It
would be great to add a test case for this to the test suite. EEXIST seems
reasonable.
--matt
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
