From: "Udo Grabowski (IMK)" <udo.grabowski@kit.edu>
To: <discuss@lists.illumos.org>
Subject: Re: [discuss] Cannot receive older ZFS dumps
Date: Mon, 5 Aug 2024 14:03:29 +0200 [thread overview]
Message-ID: <c576df9d-c4d6-bc54-bca4-7906a459270c@kit.edu> (raw)
In-Reply-To: <76876C7E-C1AC-4B90-B8F2-CBCD89D77FEC@me.com>
[-- Attachment #1: Type: text/plain, Size: 5080 bytes --]
On 05/08/2024 10:57, Toomas Soome via illumos-discuss wrote:
>
>
>> On 5. Aug 2024, at 11:03, Udo Grabowski (IMK) <udo.grabowski@kit.edu> wrote:
>>
>> On 02/08/2024 19:21, Toomas Soome via illumos-discuss wrote:
>>>
>>>> .....
>>>
>>> I’m afraid it is related to specific feature; we would need to get list of
>>> enabled and active features from receiving side (as sending side does not
>>> have features).
>>>
>>> And then there is a question what is specific about that file which is
>>> triggering the receive error… is it possible to get hands on send stream maybe?
>>>
>>> (I’m investigating one send+receive case which is triggering receiving pool
>>> to get to suspended state and it is quite a challenge).
>>
>> Here is the ZFS dump (1.8GB) <https://imk-asf-mipas.imk.kit.edu/users/grabow/> :
>>
>> 32@20100825
>> 32@20100825_xxhsum
>> features_importable
>> features_nonimportable
>>
>> + xxhsum checksum , + features active/enabled on 2018/4 pool where
>> it can be imported, and features on a very recent pool where it can't.
>> The zfs filesystem contained is Results/imk/32.
>
> ok, so the feature difference is:
>
> tsoome@beastie:~/zfs-receive-problem$ diff -u features_*
>
> --- features_importable E aug 5 11:30:53 2024
>
> +++ features_nonimportable E aug 5 11:32:31 2024
>
> @@ -1,4 +1,4 @@
>
> -OI Hipster 2018/4
>
> +OI Hipster illumos-5a33fb2d62 (>2024/4)
>
> rpool feature@async_destroy enabled local
>
> rpool feature@empty_bpobj active local
>
> rpool feature@lz4_compress active local
>
> @@ -6,11 +6,12 @@
>
> rpool feature@spacemap_histogram active local
>
> rpool feature@enabled_txg active local
>
> rpool feature@hole_birth active local
>
> -rpool feature@extensible_dataset enabled local
>
> +rpool feature@extensible_dataset active local
>
> rpool feature@embedded_data active local
>
> rpool feature@bookmarks enabled local
>
> rpool feature@filesystem_limits enabled local
>
> rpool feature@large_blocks enabled local
>
> +rpool feature@large_dnode enabled local
>
> rpool feature@sha512 enabled local
>
> rpool feature@skein enabled local
>
> rpool feature@edonr enabled local
>
> @@ -18,3 +19,10 @@
>
> rpool feature@obsolete_counts enabled local
>
> rpool feature@zpool_checkpoint enabled local
>
> rpool feature@spacemap_v2 active local
>
> +rpool feature@allocation_classes enabled local
>
> +rpool feature@resilver_defer enabled local
>
> +rpool feature@encryption enabled local
>
> +rpool feature@bookmark_v2 enabled local
>
> +rpool feature@userobj_accounting active local
>
> +rpool feature@project_quota active local
>
> +rpool feature@log_spacemap active local
>
> tsoome@beastie:~/zfs-receive-problem$
>
>
> IMO the first suspects are added active
> features: extensible_dataset, userobj_accounting, project_quota, log_spacemap.
>
> So one test scenario would be to test newer build, but with those features
> disabled, if receive is good, then enable one feature and re-test, till we have
> suspect:)
>tps://illumos.topicbox.com/groups/discuss/T575f82eecd117456-M7cca1547d1a99b935668d909>
>
Doesn't help at all, so that problem does not seem to be related to features:
# zpool create -o feature@extensible_dataset=disabled -o
feature@userobj_accounting=disabled -o feature@project_quota=disabled -o
feature@log_spacemap=disabled -o feature@allocation_classes=disabled -o
feature@large_dnode=disabled -o feature@encryption=disabled -o
feature@spacemap_v2=disabled -o feature@bookmark_v2=disabled -o
feature@obsolete_counts=disabled -o feature@zpool_checkpoint=disabled -o
feature@async_destroy=disabled -o feature@empty_bpobj=disabled -o
feature@lz4_compress=disabled test /tmp/pool
# cat /home/lsdf/SAT/Processor/Results/imk/32@20100825 | zfs receive -d test
cannot receive new filesystem stream: invalid backup stream
#
--
Dr.Udo Grabowski Inst.of Meteorology & Climate Research IMK-ASF-SAT
https://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology https://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5804 bytes --]
next prev parent reply other threads:[~2024-08-05 12:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 10:38 Udo Grabowski (IMK)
2024-08-01 10:53 ` [discuss] " Toomas Soome
2024-08-01 12:26 ` Udo Grabowski (IMK)
2024-08-02 4:55 ` Joshua M. Clulow
2024-08-02 17:09 ` John D Groenveld
2024-08-02 17:21 ` Toomas Soome
2024-08-02 19:28 ` Richard Lowe
2024-08-05 8:03 ` Udo Grabowski (IMK)
2024-08-05 8:57 ` Toomas Soome
2024-08-05 12:03 ` Udo Grabowski (IMK) [this message]
2024-08-05 21:33 ` Joshua M. Clulow
2024-08-05 7:42 ` Udo Grabowski (IMK)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c576df9d-c4d6-bc54-bca4-7906a459270c@kit.edu \
--to=udo.grabowski@kit.edu \
--cc=discuss@lists.illumos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).