|Disk Storage / Disk Store Management|
You can take several actions to optimize disk store use and data loading at startup.
When your disk store is offline, you can keep the configuration for its regions up-to-date with your cache.xml and API settings. The disk store retains region capacity and load settings, including entry map settings (initial capacity, concurrency level, load factor), LRU eviction settings, and the statistics enabled boolean. If the configurations do not match at startup, the cache.xml and API override any disk store settings and the disk store is automatically updated to match. So you do not need to modify your disk store to keep your cache configuration and disk store synchronized, but you will save startup time and memory if you do.
gfsh>alter disk-store --name=myDiskStoreName --region=/partitioned_region --disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir --initialCapacity=20
To list all modifiable settings and their current values for a region, run modify-disk-store with no actions specified.
gfsh>alter disk-store --name=myDiskStoreName --region=/partitioned_region --disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir
This applies to the removal of regions while the disk store is offline. Regions you destroy through API calls are automatically removed from the disk store.
In your application development, when you discontinue use of a persistent region, remove it from the member’s disk store as well.
gfsh>alter disk-store --name=myDiskStoreName --region=/partitioned_region --disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir --remove
You might remove a region from your application if you decide to rename it or to split its data into two entirely different regions. Any significant data restructuring can cause you to retire some data regions.
To guard against unintended data loss, GemFire maintains the region in the disk store until you manually remove it. Regions in the disk stores that are not associated with any region in your application are still loaded into temporary regions in memory and kept there for the life of the member. The system has no way of detecting whether the cache region will be created by your API at some point, so it keeps the temporary region loaded and available.