[
https://issues.apache.org/jira/browse/OAK-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348105#comment-15348105
]
Thomas Mueller commented on OAK-4492:
-------------------------------------
For file system that support hard links (I don't think all NFS servers support
that), an alternative is to use the path, node name, property name, property
index, and revision as the directory / file name. Without hard links, some
operations would probably be quite slow (and possibly dangerous), such as
versioning.
> FileDataStore with configurable path based structure
> ----------------------------------------------------
>
> Key: OAK-4492
> URL: https://issues.apache.org/jira/browse/OAK-4492
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob
> Environment: external File Data Store
> Reporter: Dheeraj Khanna
> Labels: features
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
