On 01/08/2024 12:53, Toomas Soome via illumos-discuss wrote: > > >> On 1. Aug 2024, at 13:38, Udo Grabowski (IMK) wrote: >> >> Hi, >> >> it seems that older zfs images (from zfs send) cannot be imported >> into recent illumos versions. These are dumps from a "pre-features" >> zpool. I get >> >> ro suntc ~ # cat 32@20100825 | zfs receive -d rpool >> cannot receive new filesystem stream: invalid backup stream > > > Since we virtually do not develop zfs, it is rather hard to say, but it does sound like bug. However, if you can receive it to pre-feature pool, I would upgrade pre-features pool and then check the send+receive again (from upgraded pool). > Did some more testing, could also import it on an 8 years old pool (illumos-a90d75b) with all the features (known at that time) active or enabled: async_destroy empty_bpobj lz4_compress multi_vdev_crash_dump spacemap_histogram enabled_txg hole_birth extensible_dataset embedded_data bookmarks filesystem_limits large_blocks sha512 skein edonr Unknown at that time were large_dnode device_removal obsolete_counts zpool_checkpoint spacemap_v2 allocation_classes resilver_defer encryption bookmark_v2 userobj_accounting project_quota log_spacemap Maybe one of that is to blame for the incompatibility, or it's a completely different bug. The error appears near the end of the zfs receive. As I still have the original filesystems, and the old ones are not that large, I will recreate the dumps. But in principle, zfs should preserve the ability to import older versions as much as possible, or at least have some up to date information what versions are supported for a particular new version. And it should then fail with a version mismatch (if it is such) as the error message. By the way, for upgrading older OS versions I tested importing new zfs dumps into an old zpool (without actually booting into the old OS, but for booting into the new one and then upgrading the old zpool), but that doesn't work either (probably expectable), the zfs receive hangs itself into an uninterruptible state after a while. But I won't complain for that one, for obvious reasons ... >> while I can still import those on an older illumos (in oi151.a8). >> >> This is what zstreamdump sees: >> >> # cat 32@20100825|zstreamdump >> BEGIN record >> hdrtype = 1 >> features = 0 >> magic = 2f5bacbac >> creation_time = 4c751a60 >> type = 2 >> flags = 0x0 >> toguid = d5549c3062863864 >> fromguid = 0 >> toname = Processor/Results/imk/32@20100825 >> END checksum = ac3419bb76a98f7/9a5ac336e407bdf3/c07a3f469bc7e40e/f03a369ef26634ee >> SUMMARY: >> Total DRR_BEGIN records = 1 >> Total DRR_END records = 1 >> Total DRR_OBJECT records = 131771 >> Total DRR_FREEOBJECTS records = 716 >> Total DRR_WRITE records = 133062 >> Total DRR_WRITE_BYREF records = 0 >> Total DRR_WRITE_EMBEDDED records = 0 >> Total DRR_FREE records = 300918 >> Total DRR_SPILL records = 0 >> Total records = 566469 >> Total write size = 1690867200 (0x64c89600) >> Total stream length = 1902392632 (0x71643538) >> >> Is this a bug or are "non-feature" dumps in general not importable >> on "feature"-zpools ? >> -- >> 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 >> > > ------------------------------------------ > illumos: illumos-discuss > Permalink: https://illumos.topicbox.com/groups/discuss/T575f82eecd117456-M86e91c6b85ba15613f8f79c2 > Delivery options: https://illumos.topicbox.com/groups/discuss/subscription > -- 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