Recursive ZFS snapshots are not properly destroyed

akatrevorjay commented 12 years ago

This seems to happen only when a child dataset contains a zvol. ZoL seems to not be able to recursively delete zvol snapshots giving "Invalid Argument", error code 134.

I prepared a quick hack to fix this in the interim, but IMO recursion should be moved from FLAGS to a variable of it's own, or some other nicer way that I'm not seeing ;) (explained futher in diff)

I'm not quite sure how to attach a commit to an issue, but here's the link: https://github.com/akatrevorjay/zfs-auto-snapshot/commit/e6cd6d6742e03f9a28bbdfb8517e1dd7753fc2bb

A bit off-topic: If anyone gets 'Device is busy' errors while destroying snapshots on zvols and you use multipathd:

I found that even though I had set multipathd to a wwid whitelist-only (blacklisted wwid "*") configuration, it was still locking my zvol device nodes, as it does with managed root devices (giving access only to it's partitions).
I had to blacklist devnode "zd[0-9]*" as well, for some reason not known to me yet. Perhaps someone more multipath-savvy could elaborate as to why this is?

dajhorn commented 12 years ago

This bug is tracked as zfsonlinux/zfs#696 upstream.

http://github.github.com/github-flavored-markdown/ describes how to attach commits to an issue.

In this case, if you put dajhorn/zfs-auto-snapshot#6 into a commit message, then Github will automatically crosslink the two objects.

wasurerarenai commented 12 years ago

Looking forward to seeing this fixed. I network boot iSCSI/SRP hybrid targets from my ZFS server. Targets are stored in ZVOLs and I was seeing the same issue.Trying the quick fix now with backups.

zfsonlinux / zfs-auto-snapshot

Recursive ZFS snapshots are not properly destroyed #6