[
https://issues.apache.org/jira/browse/LUCENE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960218#comment-13960218
]
Uwe Schindler commented on LUCENE-5570:
---------------------------------------
One more addition: I am not sure if the whole workflow, Lucene uses to force
syncing are actually working on all operating systems like we have them. The
javadocs of FleChannel and FileDescriptor only say that all changes made with
this file descriptor resp. this FileChannel are written to disk:
{quote}
If this channel's file resides on a local storage device then when this method
returns it is guaranteed that all changes made to the file since this channel
was created, or since this method was last invoked, will have been written to
that device. This is useful for ensuring that critical information is not lost
in the event of a system crash.
This method is only guaranteed to force changes that were made to this
channel's file via the methods defined in this class. It may or may not force
changes that were made by modifying the content of a mapped byte buffer
obtained by invoking the map method. Invoking the force method of the mapped
byte buffer will force changes made to the buffer's content to be written.
{quote}
In my opinion, the sync() should be done by the IndexOutput (e.g. before
closing). But thats another issue to solve.
> FSDirectory's fsync() is lenient
> --------------------------------
>
> Key: LUCENE-5570
> URL: https://issues.apache.org/jira/browse/LUCENE-5570
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/store
> Reporter: Robert Muir
> Attachments: LUCENE-5570.patch, LUCENE-5570.patch,
> LUCENE-5570_zerobyte.patch
>
>
> This method has a lot of problems:
> 1. it tracks 'stale files' as it writes (this seems pointless), and only
> actually fsyncs the intersection of that 'stale files' and the filenames
> passed as argument to sync(). So any bogus names passed to sync() are just
> silently ignored
> 2. if "something bad happens" (e.g. two indexwriters/dirs on the same path,
> or some other shenanigans), and the file is actually in stale files, but was
> say actually deleted on the filesystem, the underlying fsync() call will
> create a new 0-byte file and fsync that.
> In my opinion we should do none of this. we should throw exceptions when this
> stuff is wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
