From nobody Mon Jul 4 14:22:17 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D39A782F3F5 for ; Mon, 4 Jul 2022 14:22:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lc7LM4r0lz3Kdn; Mon, 4 Jul 2022 14:22:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt1-f180.google.com with SMTP id r2so10030459qta.0; Mon, 04 Jul 2022 07:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NyXY5raPoynetenH75x5EFSUmcB+131w8UeVyt788gY=; b=e9ievPCfwv4A+pJOBcYf5rx7qfvGTXz24yiO9VwC8CNuETgtV75Wjvvnny35k9ZYrM d19FRUnyp1MssDGRTrolF4jotBZmRkCRuiKFL8NRI4w/ZZ97cxb7naDTedYuYzX9LnRp c576abvBGxu+CUF15QsupgS4dBkwz+X/3tqZ+7DGlszhWaL9sQqG8KAn10ReLM6gXLaE xRQm8aNh7dWJ32TGhVArg0XVyNtBrmfDm7qFBcSTRMvfR+RNqU0Gcl5w/x76HStIw8SH RWNUH2UIcELNev0rsxbvezTjQFNUvdPq7Oh/xuowzCdeEehzz6lJ+hmbQxSE/itOCtC3 la+Q== X-Gm-Message-State: AJIora9LaHOjk+KFCAMTUaVd4bh4J8bVp08c92LQb252bY5smcC8YaX0 lpT32BkP1UczDKbYLYdE+f66FIFgZU2j4mbYDiT4MbeG1aE= X-Google-Smtp-Source: AGRyM1vTXnSmUhZwIDMzGFzSJnpgaACQICF7KIUSpm5bnSz82BwfbpwOxIToa6svm5rcBIBkzcrpWoquX5ylniPCeW4= X-Received: by 2002:a05:622a:610:b0:31e:793b:6254 with SMTP id z16-20020a05622a061000b0031e793b6254mr3046012qta.52.1656944548790; Mon, 04 Jul 2022 07:22:28 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <83C5ABFD-F786-4074-8D0D-F60E4B5E7A01@nispuk.com> In-Reply-To: <83C5ABFD-F786-4074-8D0D-F60E4B5E7A01@nispuk.com> From: Alan Somers Date: Mon, 4 Jul 2022 08:22:17 -0600 Message-ID: Subject: Re: Problem ZFS send / receive 13.1-RELEASE To: thilo jeremias Cc: Alan Somers , freebsd-stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Lc7LM4r0lz3Kdn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.539]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.180:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.180:from]; MLMMJ_DEST(0.00)[freebsd-stable]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N 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 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 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 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 >> >> >