I am running omnios r151008 on a recent box with 3gig SAS disks arranged in a raidz2 pool.
I have this 7TB filesystem where I have my zimbra server store its backups. The backup-sets are highly redundant, so for a time I had deduplication turned on to great effect, but as the size of the backup-sets grew, I ran out of ram and performance on the system became realy bad. So I turned deduplication of. Performance for newly written data is fine again. The other day, I destroyed a bunch of old snapshots on this filesysem. Thanks to background destruction this did not realy take a long time. But now as background destruction is progressing, the system remains very slugish when doing io on the pool where the destruction is taking place. I put up some graphs and raw data on http://tobi.oetiker.ch/background-destruction/ to show the state of things. My Questions: a) would it be faster to send/receive the content of the deduplicated filesystem to a new non deduplicated and then destroy the entire filesystem (not the pool). b) is there a way to monitor progress on the background destruction? c) shouldn't the smarter write throttle change https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e have helped with this by makeing zfs do its internal things with a lower priority. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900 ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
