On Jun 25, 2012, at 10:55 AM, Philip Brown wrote:
> I ran into something odd today:
>
> zfs destroy -r random/filesystem
>
> is mindbogglingly slow. But seems to me, it shouldnt be.
> It's slow, because the filesystem has two snapshots on it. Presumably, it's
> busy "rolling back" the snapshots.
> but I've already declared by my command line, that I DONT CARE about the
> contents of the filesystem!
> Why doesnt zfs simply do:
>
> 1. unmount filesystem, if possible (it was possible)
> (1.5 possibly note "intent to delete" somewhere in the pool records)
> 2. zero out/free the in-kernel-memory in one go
> 3. update the pool, "hey I deleted the filesystem, all these blocks are now
> clear"
>
>
> Having this kind of operation take more than even 10 seconds, seems like a
> huge bug to me. yet it can take many minutes. An order of magnitude off. yuck.
Agree. Asynchronous destroy has been integrated into illumos. Look for it soon
in the distributions derived from illumos soon. For more information, see Chris
Siden and Matt Ahrens discussions on async destroy and ZFS feature flags at
the ZSF Meetup in January 2012 here:
http://blog.delphix.com/ahl/2012/zfs10-illumos-meetup/
-- richard
--
ZFS and performance consulting
http://www.RichardElling.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
