I am only doing the single volume right now.
I have free space in the aggr, but only 15% free in the vol - would stopping the dedup process and growing the vol have any benefit? Also, could the reallocate measure be run which the deup scan is in progress? I can consider migrating the openvz vms, but I would prefer to do things on the existing volume..
Thanks Chris
On 2013/07/27 6:11 AM, Klise, Steve wrote:
If the alignment is ok on your vm's, maybe do a reallocate measure on the vol. I assume there is space in the aggr and vol. . If its not a pain, maybe move the data out (storage vmotion), destroy and recreate the vol and dedupe again. Should not take that long in my opinion. Oh, stupid question: your not deduping all the vols at the same time? I would figure not.
----- Original Message ----- From: Chris Picton [mailto:chris@picton.nom.za] Sent: Friday, July 26, 2013 09:04 PM To: toasters@teaparty.net toasters@teaparty.net Subject: sis start -s causing system slowdown
Hi all
One of the volumes exported via NFS from my fas3210 didn't have dedup enabled when comissioned. It is 250GB, and hosts ploop backed openvz vms. It is currently using about 210GB, and hourly snapshot size is about 6GB.
When I run sis start -s on this volume, the entire system slows down to a crawl. My snmp monitoring start timing out, ssh access to the system is hit and miss, taking over a minute to log in, and when logged on, command response is sluggish. I also get the following error in the logs for all snapmirror pairs
SnapMirror: source transfer from TEST_TESTVOL to xx.yy.zz:TEST_TESTVOL : request denied, previous request still processing.
Fortunately, disk access from clients on this and other volumes are not detrimentally affected, but IO response times do go up by about 100ms.
After running overnight for 11 hours, sis status reports Progress: 19333120 KB Scanned Change Log Usage: 88% Logical Data: 151 GB/49 TB (0%)
At this rate, it will take about 5 days to finish scanning, leaving me barely able to manage the system effectively while this is happening.
Is this normal behaviour - do I just have to wait through it, or can I stop it and correct something before trying again. Also, is the change log filling up towards 100% something to worry about?
Regards Chris
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters