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>