lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3237) FSDirectory.fsync() may not work properly
Date Wed, 07 Sep 2011 14:21:09 GMT


Shai Erera commented on LUCENE-3237:

It could be, and generally I think that it makes sense. Only the Java documentation is not
so explicit about it - I wish it was. Because if Java was explicit, it would mean we wouldn't
need to wonder what do the "man pages" say about this on Windows, AIX etc.

If others think that it makes sense that sync() affects all existing buffers, then I don't
mind if we close that issue. We haven't seen any problems with this implementation so far,
so it kinda reassuring ...

> FSDirectory.fsync() may not work properly
> -----------------------------------------
>                 Key: LUCENE-3237
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: core/store
>            Reporter: Shai Erera
>             Fix For: 3.4, 4.0
> Spinoff from LUCENE-3230. FSDirectory.fsync() opens a new RAF, sync() its FileDescriptor
and closes RAF. It is not clear that this syncs whatever was written to the file by other
FileDescriptors. It would be better if we do this operation on the actual RAF/FileOS which
wrote the data. We can add sync() to IndexOutput and FSIndexOutput will do that.
> Directory-wise, we should stop syncing on file names, and instead sync on the IOs that
performed the write operations.

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message