Citrix ShareFile Files can be hosted in the Citrix Managed cloud, or a Customer Managed Cloud. For a Customer Managed Cloud a StorageZone Controller needs to be placed within the boundaries of your own datacenter. Up to and including StorageZone Controller version 2.2, Citrix Sharefile stored all the files within one single folder. In very large environments this could lead to some challenges due to the large amount of files within one single folder. Some time ago I wrote a blog “Citrix ShareFile : Lessons learned in real life“, in which I discussed the maximum number of files supported by the storage array.

Up to and including StorageZone Controller 2.2 all zone files were stores in a single folder.

Recently Citrix ShareFile released a new StorageZone Controller version 2.3, which contains some interesting new features:

  • More files per zone
  • File upload latency testing

With this new release, according to the eDocs StorageZone Controller version 2.3 is able to handle more files per zone. Unfortunately the documentation about this new feature is limited. Let me start to explain how ShareFile accomplished this, how to enable and configure this new feature.

By default the feature to support more files per zone is switched off. To enable this new feature you need to update a registry key on all StorageZone Controllers in your zone.


Next we need to change a additional registry key, which is responsible for the number of root en sub folders being created within the “persistentstorage” folder. The following example creates 256 root folders and 256 child folders per root folder. A more detailed explanation can be found on the Citrix eDocs


Restart IIS on all the StorageZones Controllers when you are finished editing the registry.

The StorageZone Controller feature to store files in multiple folders is switched off by default

After we have made all the required registry changes our StorageZone Controller is ready to support files in multiple folders, but what will happen with my existing data? The documentation isn’t very clear on this subject, so I had to contact ShareFile product management. My main questions where :

  • Currently we have a single folder, with millions of files. Are the current files within the root folder automatically divided across the new folder structure?
  • If files are being moved into the new folder structure will there be a performance impact ?
  • Which StorageZone Controller (and service) is responsible for the file migration (if any)?

ShareFile product management was able to clarify my questions in no time. The current files will remain in the root of the “persistentstorage” folder, only new files will take advantage of the new folder structure. This means enabling the new feature will not decrease the performance, while the current structure is not being changed.

Existing files within the “persistentstorage” root folder aren’t moved into the new folder structure automatically and won’t take advantage of an improved performance

Although the answer was pretty straight forward, it wasn’t really the answer I was looking for. I our case we definitely wanted to move the data into this new folder structure, because we were told it would probably increase our overall ShareFile performance. But since the existing data isn’t migrated automatically into the new folder structure, how were we going to accomplish this?

Citrix ShareFile advised us to create a new ShareFile StorageZone, consisting of version 2.3 StorageZone Controllers (with the new feature enabled) and migrate all data from the old to the new improved Storagazone.

Currently a StorageZone migration is the only method to migrate existing “persistentstorage” folder data into the new folder structure

Unfortunately this isn’t really what I hoped for, migrating large amounts of data from one to another zone can take forever depending on the size of your “persistentstorage” folder. It would be nice if the ShareFile team developed a automated migration scenario or migration service/tool, in which the existing data can be upgraded more efficient than doing a manual StorageZone migration. Meanwhile we’ll start to prepare some test migrations to retrieve statistics which could give us a better indication on performance and timetables we need to finalize a move.

I will keep this blog up to date with the findings on out migration tests.

Post Navigation