[ https://issues.apache.org/jira/browse/LUCENE-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248485#comment-16248485 ]
Robert Muir commented on LUCENE-8048: ------------------------------------- I think any filesystem that behaves in this way on crash is choosing to corrupt users data by reflecting some later directory entries but not former ones. But linux filesystems are straight up buggy as shit around this functionality so it wouldnt surprise me. So like i said, i like the extra sync before rename to try to coerce better behavior on crash during fsync(dir). > Filesystems do not guarantee order of directories updates > --------------------------------------------------------- > > Key: LUCENE-8048 > URL: https://issues.apache.org/jira/browse/LUCENE-8048 > Project: Lucene - Core > Issue Type: Bug > Reporter: Nikolay Martynov > > Currently when index is written to disk the following sequence of events is > taking place: > * write segment file > * sync segment file > * write segment file > * sync segment file > ... > * write list of segments > * sync list of segments > * rename list of segments > * sync index directory > This sequence leads to potential window of opportunity for system to crash > after 'rename list of segments' but before 'sync index directory' and > depending on exact filesystem implementation this may potentially lead to > 'list of segments' being visible in directory while some of the segments are > not. > Solution to this is to sync index directory after all segments have been > written. [This > commit|https://github.com/mar-kolya/lucene-solr/commit/58e05dd1f633ab9b02d9e6374c7fab59689ae71c] > shows idea implemented. I'm fairly certain that I didn't find all the places > this may be potentially happening. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org