lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Updated: (LUCENE-702) Disk full during addIndexes(Directory[]) can corrupt index
Date Tue, 12 Dec 2006 12:54:25 GMT
     [ ]

Michael McCandless updated LUCENE-702:

    Attachment: LUCENE-702.take2.patch

OK I attached a new patch with changes to only javadocs & unit tests:

  * Fixed the disk full unit test to use "richer" documents so indexes
    shrink less on merging/optimizing (ie make the test case "harder"
    to satisfy the disk usage check).

  * Added new test case for temp disk usage of optimize.  Verified
    that it fails if we put a transaction around mergeSegments call in
    optimize (as described above).

  * Fixed javadocs for addIndexes(*): we actually require up to 2X the
    total input size of all indices.  Fixed unit test to assert this.

  * Fixed javadocs in IndexWriter's optimize, addIndexes(*),
    addDocument to describe disk usage and index state after an
    IOException is thrown.

  * Improved how MockRAMDirectory tracks/enforces max usage.

  * Other small fixes to unit test.

> 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, LUCENE-702.take2.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