Details
Major Description
Configuration for path based structure in the FDS so that we can have more granular control over FDS growth and cleanup operations. We can have a datastore root under which level 1 can be configurable on basis of number of paths needed (index, application1, application2 etc) and rest of the management of blobs under each asset can be done in the way they are done today.
Something like:
datastoreroot
| ___path1 (indexes) | ||
| __aa | ||
| __a1 | ||
| __a2 | ||
| __bb | ||
| __b1 | ||
| __b2 | ||
| ___path2 (app1) | ||
| __aa | ||
| __a1 | ||
| __a2 | ||
| __bb | ||
| __b1 | ||
| __b2 | ||
| ___path2 (archived blobs) | ||
| __aa | ||
| __a1 | ||
| __a2 | ||
| __bb | ||
| __b1 | ||
| __b2 | ||
For example:
1. datastoreroot/path1 (indexes)- folder for index binaries - so that DSGC for previous lucene index binaries can be contained in a separate area and can be run independent of application blob DSGC.
2. datastoreroot/path2 (app1)- in case there are multiple applications on the same instance. This could help with backups etc.
3. datastoreroot/path3 - folder for archival use case - Eg: In case of archival of older blobs the binaries can be moved to this location. Again helps with bringing efficiency to the 'current' data set as only current data set needs to be backed up on regular basis. Use case also requires to be able to restore a archived blob into current data set, if required.
