The only one you really have to worry about is scrub. Scrub should really only be run during times of low io contention. It will run at a high priority

I believe there is work going on the create more granular priorities..

Nfs and iscsi already run in the kernel and will be handled as quickly as possible.

Thanks for your answer Ok in fact i have already test with a scrub and it's really not possible. Particular with an esx farm. And i know some people who have trouble to destroy their snapshot. The nfs services crash or it seems crashed that's why i ask for a method to change the priority of this task.

just to precise this crash was with nexenta core maybe in nexenta stor the problem doesn't appear.

nexenta core hasn't been updated in awhile, we expect to have a newer version soon.

testing with nexentastor will give you much more accurate results.

just an fyi, during a scrub every filesystem block is read in to check the checksum. It is very resource intensive..

I'm having this issue as well. I have a zvol shared via iSCSI to 3 ESXi 4.1 hosts over dual 10G (Intel) NICs (jumbo frames through an HP ProCurve 3500yl, 2x1GB NICs per host). Whenever a scrub happens, the guest VMs appear to drop in and out because the hosts think the links to the SAN are dropping. I have read that monthly scrubs are best for Enterprise Grade disks. And this zvol houses my most important data. Is there any way to slow down the scrub? Or speed it up significantly? Right now, the scrub takes ~90 hours to complete.

PogoLinux Storage DirectorZ2 w 24GB RAM and Intel E5645 CPUs @ 2.4GHz

6x600GB SAS2 15K Seagates in RAIDZ2 2x 32GB Intel x-25e SSDs as LOG 1x64GB Intel x-25e SSD as CACHE

Out of the above volume, I carved out about 1.5TB for the DataStore. I'm thinking I should create a second DataStore on a second volume made of many mirrors for an additional 1.5TB and SSDs for cache/log. This scrub issue is really affecting my users. I run the scrub over the weekend, but it's taking forever. Any ideas? Thanks!