[ http://issues.apache.org/jira/browse/LUCENE-702?page=comments#action_12457520 ] 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: 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 > 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: 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]
