Folks,
I've been seeing this for a while, but never had the urge to ask, until now.
When I take a snapshot of my current root-FS and tell the system to reboot off
that snapshot, I'm faced with an assertion failure (running DEBUG bits) that
looks like this:
r...@codemonkey:~# df -h /
Filesystem
> That still doesn't wait for zfs destroy. Zfs destroy is run in a
> sub-shell "()" and you wait for that sub-shell but not for its children.
If I extend the command with an additional "zfs list", all the
filesystems that I told the system to destroy are gone...
Joep
__
On 04/17/09 21:19, Kyle McDonald wrote:
> One reason is that you're not timing how long it takes for the destroy's
> to complete. You're only timing how long it takes to start all the jobs
> in the background.
Right, I'm sorry, my example was an oversimplification of a script I made.
That script
All,
I was wondering why "zfs destroy -r" is so excruciatingly slow compared to
parallel destroys.
On my x4500, for example, after having created 1000 filesystems named
pool/blub2/
[...]
pool/blub2/0999
and keeping them empty, a subsequent destroy with
# time zfs destroy -r poo
