> On 2. Aug 2024, at 20:09, John D Groenveld via illumos-discuss 
> <discuss@lists.illumos.org> wrote:
> 
> In message <1c2abfa3-df73-91cb-79da-c34eaeca3...@kit.edu>, "Udo Grabowski 
> (IMK)" writes:
>> 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 enab=
>> led:
> 
> I'm not able to reproduce.
> Here's my test procedure:
> Booted 151a8
> Created two pools:
> # mkfile 64M /root/features
> # mkfile 64M /root/version28
> # zpool create features /root/features
> # zpool create -d -o version=28 version28 /root/version28
> # zfs create features/test
> # zfs create version28/test
> # dd if=/dev/urandom of=/features/test/wee bs=1024k count=16
> # md5sum /features/test/wee
> # cp /features/test/wee /version28/test/
> # md5sum /version28/test/wee
> # zfs snapshot features/test@foo
> # zfs snapshot version28/test@bar
> # zfs send features/test@foo>features.snapshot
> # zfs send version28/test@bar>version28.snapshot
> 
> copy the snapshots to today's OI, illumos-533d257436
> 
> # zfs receive -v rpool/features< features.snapshot
> # zfs receive -v rpool/version28< version28.snapshot
> # md5sum rpool/features/test/wee
> # md5sum rpool/version28/test/wee
> 
> John
> groenv...@acm.org

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).

rgds,
toomas


------------------------------------------
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/T575f82eecd117456-M28bbf962056ad33fb177e3c8
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to