How do I delete a corrupted child dataset?

[Redsandro]

I am trying to upgrade an old compiled from source ZFS 0.7.0-133_g35df0bb55 release candidate to the latest stable version, and rebuild the related dataset called pool.

These are the steps I planned on taking.

1. Create new dataset backup on temporary storage.
2. ZFS send old pool to backup
   • a) send ENCRYPTED=NO datasets first (majority of data)
   • b) send ENCRYPTED=YES datasets using --raw or -w
3. Upgrade ZFS, destroy and recreate pool with new version.
4. Mount backup as read-only
5. rsync backup to pool
6. destroy backup

The problem starts with 2b: sending encrypted datasets. I had already made the main backup pool. This is how I transfered the encrypted datasets:

for F in data data/www data/footage data/foley data/projects; do \
  zfs create -o mountpoint=/mnt/backup/$F backup/$F
  zfs send --raw pool/$F | pv | zfs receive -u -F backup/$F
done

The encrypted datasets show up as unencrypted on the destination, and cannot be mounted. Something clearly went wrong. So I want to destroy them, and try again with rsync. However, I cannot remove them:

# zfs destroy -f backup/data/www
cannot destroy 'backup/data/www': filesystem has children
use '-r' to destroy the following datasets:
backup/data/www@--head--
# zfs destroy -rf backup/data/www
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

The command hangs indefinitely (although this is a mini dataset which should be done in under a minute)

I would like to destroy all the encrypted datasets and try again by manually using rsync in stead. If I have to destroy the whole pool, I wil loose many terabytes of already copied unencrypted data, and it will set me back two days.

Is it possible to recursively destroy backup/data and keep the backup itself alive?

[sempervictus]

What does dmesg say about this?

[Redsandro]

I didn't think about checking that. Was just wondering if there was a simple method of force removing a stuck dataset copied in defiance of Errata #4.

Since not a lot of people are using the release candidates beyond testing, I figured it was not worth investigating in-depth. I have since destroyed the pool and compiled OpenZFS 2.0.3 where the original pool can be mounted as read-only. Using rsync now and the copy will be done in a few days.

Lesson for others: Upgrade ZFS first, then make a the temporary copy instead of the other way around.