[ 
http://issues.apache.org/jira/browse/LUCENE-702?page=comments#action_12446376 ] 
            
Michael McCandless commented on LUCENE-702:
-------------------------------------------


That seems like a reasonable approach?  At least the index would be
consistent (ie, loadable).

Though, if you hit disk full part way through, then some of your
indexes were added and some where not.  How do you "recover" after you
free up your disk space?  If you just re-add all indexes then you have
duplicates in the index.

Is it possible instead to not reference (in the written segments info
file) those segments that were carried over from the input
readers/directories?  This would make the operation transactional, so
that if we crashed part way through, then the index rolls back to
where it was before the addIndexes call.  And user could free up disk
space and try again, without creating dups.

(One problem with this is that the orphan'd segments that had been
written would not actually get deleted automatically; lockless commits
would fix that though because it recomputes on instantiating a reader
which files are unreferenced and then deletes them).


> Disk full during addIndexes(Directory[]) can corrupt index
> ----------------------------------------------------------
>
>                 Key: LUCENE-702
>                 URL: http://issues.apache.org/jira/browse/LUCENE-702
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.1
>            Reporter: Michael McCandless
>         Assigned To: Michael McCandless
>
> This is a spinoff of LUCENE-555
> If the disk fills up during this call then the committed segments file can 
> reference segments that were not written.  Then the whole index becomes 
> unusable.
> Does anyone know of any other cases where disk full could corrupt the index?
> I think disk full should worse lose the documents that were "in flight" at 
> the time.  It shouldn't corrupt the index.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to