lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ning Li (JIRA)" <>
Subject [jira] Commented: (LUCENE-702) Disk full during addIndexes(Directory[]) can corrupt index
Date Tue, 12 Dec 2006 00:25:22 GMT
    [ ] 
Ning Li commented on LUCENE-702:

It looks good. My two cents:

1 In the two rollbacks in mergeSegments (where inTransaction is false), the segmentInfos'
generation is not always rolled back. So something like this could happen: two consecutive
successful commits write segments_3 and segments_5, respectively. Nothing is broken, but it'd
be nice to roll back completely (even for the IndexWriter instance) when a commit fails.

2 Code serving two purposes are (and has been) mixed in mergeSegments: one to merge segments
and create compound file if necessary, the other to commit or roll back when inTransaction
is false. It'd be nice if the two could be separated: optimize and maybeMergeSegments call
mergeSegmentsAndCommit, which creates a transaction, calls mergeSegments and commits or rolls
back; mergeSegments doesn't deal with commit or rollback. However, currently the non-CFS version
is committed first even if useCompoundFile is true. Until that's changed, mergeSegments probably
has to continue serving both purposes.

> Disk full during addIndexes(Directory[]) can corrupt index
> ----------------------------------------------------------
>                 Key: LUCENE-702
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.1
>            Reporter: Michael McCandless
>         Assigned To: Michael McCandless
>         Attachments: LUCENE-702.patch
> 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message