Formerly, if you interrupted a zfs receive, it would leave a clone with a % in its name, and you could find it via "zdb -d" and then you could destroy the clone, and then you could destroy the filesystem you had interrupted receiving.
That was considered a bug, and it was fixed, I think by Sun. If the lingering clone was discovered laying around, zfs would automatically destroy it. But now I'm encountering a new version of the same problem... Unfortunately, now I have a filesystem where "zfs receive" was interrupted, and I can't destroy the filesystem or the snapshot of the filesystem on the receiving side. sudo zfs destroy -R tank/Downloads cannot destroy 'tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54': dataset already exists sudo zfs destroy -R tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54 cannot destroy snapshot tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54: snapshot is cloned sudo zfs list -t all | grep Downloads tank/Downloads tank/Downloads@zfs-auto-snap_hourly-2012-08-31-17h54 sudo zdb -d tank/Downloads Dataset tank/Downloads [ZPL], ID 139, cr_txg 31408, 3.91G, 30 objects (Notice, I don't get any clones listed.) I'm running openindiana 151.1.6 (the latest, fully patched a couple of weeks ago.)
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
