Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Jul 2022 08:22:17 -0600
From:      Alan Somers <asomers@freebsd.org>
To:        thilo jeremias <thilo@nispuk.com>
Cc:        Alan Somers <asomers@freebsd.org>, freebsd-stable <freebsd-stable@freebsd.org>
Subject:   Re: Problem ZFS send / receive 13.1-RELEASE
Message-ID:  <CAOtMX2g3cQndvGQQaungBharLL8BCBHrcsSXJEb7T3AnZUraGQ@mail.gmail.com>
In-Reply-To: <83C5ABFD-F786-4074-8D0D-F60E4B5E7A01@nispuk.com>
References:  <C9A31AB9-19AE-4FD7-BA52-EC01D0453A3C@nispuk.com> <CAOtMX2iu4rpKiF5P7vfizbvcqZ7Mw1QtZoyrzVq%2BLRXhRR2_gA@mail.gmail.com> <83C5ABFD-F786-4074-8D0D-F60E4B5E7A01@nispuk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Yeah, it would be great if it could raise an error.  I've run into
this problem before.  However, I can't figure out how.  It's not easy,
because the two incompatible flags apply to separate commands.  The
only way I can guess how to do it would be to add a flag to the send
stream that says "the stream was generated with -R", even though said
flag wouldn't affect the received dataset.
https://github.com/openzfs/zfs/issues/9150

On Mon, Jul 4, 2022 at 8:12 AM thilo jeremias <thilo@nispuk.com> wrote:
>
> Understood.
>
> Could this be documented in the man-pages (maybe near the zfs-send =E2=80=
=9C-t=E2=80=9D option)?
> Also I think, it would be =E2=80=9Ca nice to have feature=E2=80=9D  if th=
is throws an error either at the receiving or sending side.
> (May be the sending options should be part of the transmission stream and=
 the receiver croaks?)
>
>
> Thank you!
>
> Thilo
>
>
> On 4. Jul 2022, at 15:06, Alan Somers <asomers@freebsd.org> wrote:
>
> It's not a bug. The problem is that you can't combine zfs send -R and als=
o zfs recv -s .  The former creates several independent send streams.  But =
the latter generates a token that will only resume a single stream. And the=
re's no way to fix the problem given ZFS's design. If the send gets interru=
pted,  you need to go check on the destination side to see which file datas=
ets are incomplete and resume all of them.
>
> On Mon, Jul 4, 2022, 5:53 AM thilo jeremias <thilo@nispuk.com> wrote:
>>
>> Hello everyone,
>>
>> I posted a question on ( https://forums.freebsd.org/threads/zfs-replicat=
ion-interrupted-and-resumed-missing-snapshots.85666/ )
>> Which I now think is a bug in zfs send/receive for 13.1-RELEASE
>>
>>
>> Essentially, an interrupted & restarted receive does not create all snap=
shots from the stream.
>>
>> The following:
>>
>> #Interrupted transfer
>> zfs send -R "$D@final" | dd bs=3D10m count=3D200 | zfs recv -s "$D"_bad
>>
>> #Resume transfer
>> TOKEN=3D"$(zfs get -H receive_resume_token   "$D"_bad  | cut -f 3)"
>> zfs send -t "$TOKEN" | zfs recv -s "$D"_bad
>>
>>
>> #Good transfer
>> zfs send -R "$D@final" | zfs recv -s "$D"_good
>>
>>
>>
>> Produces:
>>
>> NAME                          USED  AVAIL     REFER  MOUNTPOINT
>> Backup/testset_good@initial  85.2K      -      128K  -
>> Backup/testset_good@add100m  85.2K      -      100M  -
>> Backup/testset_good@add300m  85.2K      -      400M  -
>> Backup/testset_good@del100m  85.2K      -      300M  -
>> Backup/testset_good@del300m     0B      -      128K  -
>> Backup/testset_good@final       0B      -      128K  -
>> NAME                         USED  AVAIL     REFER  MOUNTPOINT
>> Backup/testset_bad@initial  85.2K      -      128K  -
>> Backup/testset_bad@add100m     0B      -      100M  -
>>
>>
>> Which is not correct since it misses the snapshots from the original str=
eam (=E2=80=9Cgood=E2=80=9D)
>>
>> Can this be reproduced by anyone else?
>>
>>
>> Thilo
>>
>>
>> -------------------------------
>> Dipl. Ing. Thilo Jeremias
>> Hauptstra=C3=9Fe 11
>> 35466 Rabenau
>>
>> T: +49 15782492240
>>
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2g3cQndvGQQaungBharLL8BCBHrcsSXJEb7T3AnZUraGQ>