This post is more than 5 years old
1 Rookie
•
8 Posts
0
1517
April 9th, 2018 02:00
WormQueue can it be disabled
Hello All,
we have Worm queue job running everyday at 10:00 pm on all clusters, we dont use Smartlock feature, Smartlock license is inactive as well, can i go ahead and disable WormQueue job, we have syncIQ jobs running everyday, does this affect SyncIQ or Snapshot?
-Thanks
Pradeep
AdamFox
254 Posts
0
April 9th, 2018 08:00
TL;DR - For your case, go ahead and set it to manual if you like.
You can disable it if you aren't using SmartLock. It's there to handle a race condition that can occur when changing certain parameters on a worm domain, which you obviously would not need.
As far as it affecting other jobs, in general, you won't notice. It chews up a spot in the job engine run queue when running, but it doesn't belong to an exclusion group so other than being one of the 3 jobs that can run at a time, it doesn't hurt anyone. It's priority is pretty low (6) so it will yield to more critical jobs if the job run queue fills. SnapDelete, for example, has a priority of 2 so it will take precedence over WormQueue.
SyncIQ runs outside of the job engine, so there's no effect there.
pradeep_p_s
1 Rookie
•
8 Posts
0
April 10th, 2018 00:00
Thank you Adam,
I see Wormqueue as committing files in Isilon to Worm state, and since we don't have smartlock feature, I guess keeping it disabled makes lot of sense
AdamFox
254 Posts
0
April 10th, 2018 06:00
No problem. Slightly off topic but perhaps there will be some who will read his later and care, we normally don't need the job to commit files, It usually happens anytime someone tries to do anything to a file in a worm domain. At that time, we check the commit time and if it should be committed we do so at that time. This way we don't have to wait for a job to run before something is committed as this could potentially break compliance.
But, as I eluded to earlier, there is a rare condition where this doesn't work. We have a feature called auto-commit which tells the system to commit a file after so much time after it's been written/updated. Let's say we set it for a day. But we never access it. Then a month later we turn auto-commit off and rely on manual commits. Before adding the job, the file we never accessed would not technically be committed because we never accessed it. But then after turning off autocommit, we decide to try and update or delete it. Prior to the job (which came in 7.1.1) the file would not have committed so the file could be updated even though it should have been committed after the first day. So the Wormqueue job walks the domain once day to ensure that any file that should have been autocommitted is actually committed so avoid this problem.
I would not expect many customers would run into this particular issue, but there are always unusual edge cases where we have to be sure we do the right thing, especially with compliance data.