[ 
https://issues.apache.org/jira/browse/SOLR-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691897#comment-16691897
 ] 

Erick Erickson commented on SOLR-12999:
---------------------------------------

I'm a little lost here. What's the definition of "knows will not be needed"? If 
it's a list of segments locally that are not present on the leader and 
therefore won't be necessary this seems fraught.

> if a new searcher is opened for any reason, wouldn't it fail? Restarts, rogue 
> commits, whatever.

> Wouldn't the files still  be there on *nix systems if a searcher had them 
> open?

> On Windows systems, if a searcher has the files open would the delete fail in 
> the first place?

I know you know Lucene details far better than me, so I suspect I'm totally 
missing the point.

> Index replication could delete segments first
> ---------------------------------------------
>
>                 Key: SOLR-12999
>                 URL: https://issues.apache.org/jira/browse/SOLR-12999
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: replication (java)
>            Reporter: David Smiley
>            Priority: Major
>
> Index replication could optionally delete files that it knows will not be 
> needed _first_.  This would reduce disk capacity requirements of Solr, and it 
> would reduce some disk fragmentation when space get tight.
> Solr (IndexFetcher) already grabs the remote file list, and it could see 
> which files it has locally, then delete the others.  Today it asks Lucene to 
> {{deleteUnusedFiles}} at the end.  This new mode would only be useful if 
> there is no SolrIndexSearcher open, since it would prevent the removal of 
> files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to