It might be useful to consider on filesystems where hard linking may not be available. Consider S3 based directory or a kubernetes based shared file system like ceph etc.
Maybe having both modes, file copy based and hard linking based, would be great. On Wed, 13 Apr, 2022, 3:15 am David Smiley (Jira), <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-16153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521347#comment-17521347 > ] > > David Smiley commented on SOLR-16153: > ------------------------------------- > > I guess we needn't bother with IndexWriter.addIndexes(Directory) which > although fine is more for a case of adding one/more indexes to an existing > index, thus the segment names have to be considered. For a straight > copy/link where the target will be replaced, there's similar code in > SolrIndexSplitter. > > > Clone Collection > > ---------------- > > > > Key: SOLR-16153 > > URL: https://issues.apache.org/jira/browse/SOLR-16153 > > Project: Solr > > Issue Type: New Feature > > Security Level: Public(Default Security Level. Issues are Public) > > Components: SolrCloud > > Reporter: David Smiley > > Priority: Major > > > > It should be possible to "clone" a collection, and to do so cheaply. > This might be its own command or be an option of collection creation; > either way, it'd be great to support the vast majority of the same options > of collection creation. A cloned collection should be the same in every > way (shard ranges, collection properties, replicas types and counts, etc.) > unless configured to be different (e.g. specify a different configSet). > Most importantly, a cloned collection should have the same data, and this > can be accomplished via UNIX hard links (when supported) to the underlying > files. This would make clones cheap! A no-data option should be supported > as well, useful when the intended action is to re-index subsequently. > > > > -- > This message was sent by Atlassian Jira > (v8.20.1#820001) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
