Many thanks.
Using the latest master, I can confirm that things are much improved.
It appears the problem stems from sending a raw encrypted dataset to an online, decrypted zpool (which may be unintended usage and may be a
user error on my part).
The reboots do not occur if the target zpool is not decrypted.
The reboots also do not occur if the target zpool is completely unencrypted.
SCENARIO 1: decrypted pool1 to decrypted pool2 - random reboots or Malformed Mach-o fileBackup encrypted pool1 to decrypted pool2 using --raw initially works:- Code: Select all
zfs send -Rcv --raw
However when exporting and importing pool2 containing a raw encrypted dataset, random reboots occur during the process of exporting and importing.
These random reboots are much reduced since updating to latest master.If reboot does not occur, it reports: cannot mount 'pool2/pool1-backup': Malformed Mach-o file.
At this point I am unable to export pool2: 'pool is busy'.
SCENARIO 2: decrypted pool1 to encrypted pool2 - okBackup decrypted pool1 to encrypted pool2 using --raw works:- Code: Select all
zfs send -Rcv --raw
Restore decrypted pool2 to decrypted pool1 works:- Code: Select all
zfs load-key -r pool2
zfs send -cv pool2/pool1-backup@backup | zfs recv pool1/backup
Note: do not use -R or -p as we do not want to send properties; an encrypted dataset may not be sent with properties without the raw flag; also I want the dataset to inherit properties from pool1 on restore.
The datasets are immediately mounted and available.
SCENARIO 3: decrypted pool1 to unencrypted pool2 - okBackup decrypted pool1 to unencrypted pool2 works:- Code: Select all
zfs send -Rcv --raw
The child datasets on pool2 are encrypted; checked via:
- Code: Select all
zfs get -r encryptionroot
Restore unencrypted pool2 to decrypted pool1 with --raw partially works; but I do not recommend it:The datasets are not automatically mounted on completion.
Whilst no decryption key for pool2 is required to do the restore, passphrase for each child dataset will be required at each mount.
- Code: Select all
zfs send -cv --raw
Restore unencrypted pool2 to decrypted pool1 without --raw works:N.B. If original backup was using -Rcv, only 1x passphrase required; otherwise I suspect each child dataset would require its own passphrase upon mount.
- Code: Select all
zfs send -cv
warning: cannot send: source key must be loaded
zfs load-key -r pool2
zfs send -cv
SUMMARYzfs send -Rcv --raw can backup to either encrypted (but not decrypted) targets or unencrypted targets (where it will make encrypted child datasets).
zfs send -Rcv --raw to decrypted targets results in reboots or Malformed Mach-o file
There is no point to zfs send --raw on restores.
Thank you once again for your great work