zfs code - Oct 2010 - Processing deferred delete-s on mount

I notice that rebooting with a lot of deferred delete-s may cause the boot to be
taking a fair amount of time (possibly hours) , because the deferred delete
queue is processed
before an fs can complete its mount. 
I am talking about zfs_unlinked_drain().

I wonder if this processing really needs to be done before the system can come
up,
or could it be done in a background thread, once the fs is mounted.

Some insight from the zfs team would be most appreciated, esp. regarding why
this may be a really bad idea.

TIA 

Steve
-- 
This message posted from opensolaris.org

>From digging through some of the zpool / zfs code today this routine seems
to be one of the logical places that OpenSolaris could hang after a zfs destroy
of a zvol w/ dedup on.
Perhaps setting the volume to read only first helps some? I''ve got a
hung server with lots of users waiting for it, so I can''t test that,
but it seems like destroying a zvol shouldn''t be so difficult.
-- 
This message posted from opensolaris.org

Yes, the mount certainly can hang in the drain function.

Just do an rm on  500 GB dedupe-d file and reboot.

There will be a significant delay before the machine comes up, possibly hours.

I think this could be worked around, but perhaps I am missing something.

Steve
-- 
This message posted from opensolaris.org