Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 06/05/2015 02:29, Matthew Ahrens wrote: > > > On Fri, Apr 24, 2015 at 6:29 AM, Andriy Gapon > wrote: > > > BTW, there is another boundary case for zfs_ioc_recv(). > If the desired destination snapshot already exists then EEXIST is always > return.

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 06/05/2015 02:28, Matthew Ahrens wrote: > 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. > Thank yo

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On Fri, Apr 24, 2015 at 6:29 AM, Andriy Gapon wrote: > > BTW, there is another boundary case for zfs_ioc_recv(). > If the desired destination snapshot already exists then EEXIST is always > return. > On the one hand, this totally makes sense. On the other hand, if we are > doing > force-receivi

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On Fri, Apr 24, 2015 at 4:38 AM, Andriy Gapon 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

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

[ping] I would like to get a preliminary review for the change suggested below . Or should I rather open an issue and submit the change for a review via the reviewboard? Thanks! On 24/04/2015 14:38, Andriy Gapon wrote: > On 24/04/2015 02:25, Matthew Ahrens wrote: >> I think that's a bug / not-f

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

BTW, there is another boundary case for zfs_ioc_recv(). If the desired destination snapshot already exists then EEXIST is always return. On the one hand, this totally makes sense. On the other hand, if we are doing force-receiving and the conflicting local snapshot would be destroyed if it had a

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

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

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On Thu, Apr 23, 2015 at 2:29 PM, Andriy Gapon wrote: > On 24/04/2015 00:00, Matthew Ahrens wrote: > > On Thu, Apr 23, 2015 at 1:24 PM, Andriy Gapon < > andriy.ga...@clusterhq.com> wrote: > > It seems that any filesystem is considered modified when compared to > $ORIGIN. > > And ds_prev of

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 24/04/2015 00:00, Matthew Ahrens wrote: > On Thu, Apr 23, 2015 at 1:24 PM, Andriy Gapon > wrote: > It seems that any filesystem is considered modified when compared to > $ORIGIN. > And ds_prev of a filesystem without any real snapshots points to $ORIGIN. > Or is it $ORIGIN@$ORIGIN

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On Thu, Apr 23, 2015 at 1:24 PM, Andriy Gapon wrote: > On 23/04/2015 21:12, Paul Dagnelie wrote: > > I think you're right. We should modify recv_begin_check_existing_impl > to fail > > if fromguid != 0 and force is false. If we don't, we're guaranteed to > fail in > > dsl_dataset_clone_swap_che

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 23/04/2015 21:12, Paul Dagnelie wrote: > I think you're right. We should modify recv_begin_check_existing_impl to fail > if fromguid != 0 and force is false. If we don't, we're guaranteed to fail in > dsl_dataset_clone_swap_check_impl (unless the dataset has not been modified > since the origi

[OpenZFS Developer] receiving non-incremental stream into existing fs

I think you're right. We should modify recv_begin_check_existing_impl to fail if fromguid != 0 and force is false. If we don't, we're guaranteed to fail in dsl_dataset_clone_swap_check_impl (unless the dataset has not been modified since the origin, I guess. But given that we (almost?) always mod

[OpenZFS Developer] receiving non-incremental stream into existing fs

I wonder if dmu_recv_begin_check() -> recv_begin_check_existing_impl() should fail in the following case: - full stream, fromguid == 0 - tofs already exists - tofs does not have any snapshots [*] - force is false In my opinion there is no way that this could succeed. But right now this seem to su