Thank you very much for the response! I've created a bug and added all relevant details there: https://issues.apache.org/jira/browse/LUCENE-9867 Please let me know if you have any questions, or if any other information would be helpful.
-- Regards, Alexander L On Wed, Mar 24, 2021 at 10:09 AM Michael McCandless < luc...@mikemccandless.com> wrote: > +1, this sounds like a bad bug in Lucene! We try hard to test for and > prevent such bugs! > > As long as you succeeded in at least one commit since creating the > index before you hit the disk full, restarting Lucene on the index should > have recovered from that last successful commit. > > How often do you commit? Did you have a successful commit before the disk > full event? > > Please open an issue and put all possible comments detailing your context, > thanks, > > Mike McCandless > > http://blog.mikemccandless.com > > > On Wed, Mar 24, 2021 at 12:55 PM Robert Muir <rcm...@gmail.com> wrote: > > > On Wed, Mar 24, 2021 at 1:41 AM Alexander Lukyanchikov < > > alexanderlukyanchi...@gmail.com> wrote: > > > > > Hello everyone, > > > > > > Recently we had a failed segment merge caused by "No space left on > > device". > > > After restart, Lucene failed with the CorruptIndexException. > > > The expectation was that Lucene automatically recovers in such > > > case, because there was no succesul commit. Is it a correct assumption, > > or > > > I am missing something? > > > It would be great to know any recommendations to avoid such situations > > > in future and be able to recover automatically after restart. > > > > > > > I don't think you are missing something. It should not happen. > > > > Can you please open a issue: > > https://issues.apache.org/jira/projects/LUCENE > > > > If you don't mind, please supply all relevant info you are able to > provide > > on the issue: OS, filesystem, JDK version, any hints as to how you are > > using lucene (e.g. when you are committing / how you are indexing). There > > are a lot of tests in lucene's codebase designed to simulate the disk > full > > condition and guarantee that stuff like this never happens, but maybe > some > > case is missing, or some other unknown bug causing the missing files. > > > > Thanks > > >