FSAUtility and checkpoint

[AWMorris]

Does anybody happen to know if EV 9 SP 2 has a checkpoint feature?

[TonySterling]

Yes, but there was a hotfix for sp2 or you could go to sp3

The File System Archiving Checkpoint feature is not processing through sub-folders alphabetically, which can cause the re-processing of some folders

Article: TECH163368

|

Created: 2011-06-27

|

Updated: 2011-12-21

|

Article URL http://www.symantec.com/docs/TECH163368

here is the hotfix for sp2 as well:

Hotfix for Symantec Enterprise Vault (EV) for File System Archiving 9.0.2, Build 1061 - Checkpointing is not processing through sub-folders alphabetically

Article: TECH167579

|

Created: 2011-08-19

|

Updated: 2011-08-19

|

Article URL http://www.symantec.com/docs/TECH167579

[AWMorris]

The hotfix indicates that this is for NetApp appliances.  Have you used this with other platforms?

[TonySterling]

The first article says this:

However in certain environments, such as Netapp, folders may be presented to Enterprise Vault out of alphabetical order.

It isn't exclusively for NetApp.  If you have rather deep and wide folder structure I think this will help you out. 

Regards,

[TonySterling]

It for sure won't hurt, maybe Darren L. will see this post and comment.  I believe he mentioned at Vision during an Ask the Expert session that checkpointing was improved in 9 SP3 to take less time to find where it left off.

[AWMorris]

I'll give a try, Tony....  Customer has certainly got a deep and wide folder structure.

[AWMorris]

What kind of performance have you seen with running FSAUtility -pm switch?  Darren indicated 100K in the following post.

https://www-secure.symantec.com/connect/blogs/file-system-archiving-enterprise-vault-v9-placeholder-...

We are getting anywhere near that.  Increasing the threads as follows really don't help either.

https://www-secure.symantec.com/connect/forums/using-fsautilityexe-m-s-source-d-destination-watching...

I posted the following before comparing results.  40 is no different than 20.

https://www-secure.symantec.com/connect/forums/fsautilityfolderprocessthreads

[TonySterling]

hmm, do you stop the FSA archiving task whilst running FSAUtility?

What OS are the File Servers, NTFS?

[AWMorris]

The archiving task is stopped.  We are migrating the placeholders from NTFS to Celerra.

[AWMorris]

You know what I just realized.  That hotfix is for File System Archiving not FSAUtility.

[TonySterling]

Sorry, my bad.  You did have FSAUtility in your subject but went straight to checkpointing for FSA as that was fresh on my mind from Vision.

No, FSAUtiliy will not have a checkpoint facility.

[TonySterling]

You should comment on Darrens blog with your current throughput and link to this thread, that should grab his attention.  :)

[Darren_Locke · Accepted solution]

My attention is grabbed here ;)

Certain functions in FSAUtility do have checkpointing, -pm does not though. Unfortunately migrating to Celerra will be slower than to Windows or NetApp. We use the Celerra DHSM commands to create placeholders on that platform. This is a pretty slow operation (compared to WIndows or NetApp). The numbers I quoted in the blog were when migrating to Windows. 

If you are migrating multiple shares, then you could run mutiple instances of -pm. However, ensure you do not run multiple instances against the same share.

I would also recommend upgrading to 9.0.3. While it is unlikely to get you better performance, for reliability purposes it's always best to be on the latest version of FSAUtility. 

Darren

[AWMorris]

Thanks for the reply Darren!  We are able to run multiple instances against different volumes and everything was working fine.  We have now run into a nasty memory leak that has been identified in

https://www-secure.symantec.com/connect/forums/fsautility-pm

ETrack is 2729682.  This isn't a result of running multiple instances as it happens when only running one.  I have been working with support to gather additional information but might need to call an audible as we are up against a project deadline.