[
https://issues.apache.org/jira/browse/LUCENE-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262170#comment-14262170
]
Robert Muir commented on LUCENE-6150:
-------------------------------------
I think mike's concern was to avoid huge amount of fsync calls? Maybe
especially on windows since everyone is clueless about what windows does ---->
afraid things might be slower.
I mean to me this is the OS's job to be a no-op for the ones we have "already
synced": it knows there are no modifications to those. If windows gets slower,
thats windows problem.
+1 to the patch.
> Remove staleFiles set from FSDirectory
> --------------------------------------
>
> Key: LUCENE-6150
> URL: https://issues.apache.org/jira/browse/LUCENE-6150
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6150.patch
>
>
> Hi,
> the "hack" to keep track of files written to in FSDirectory, to filter them
> when calling sync is heavily broken. [~mikemccand] already opened an issue,
> which was abandoned then.
> In fact handling this in FSDirectory is a hack and broken! If IndexWriter is
> itsself not able to correctly handle tracking the files, it is also his
> repsonsibilty to do this. We already have a class that can do this:
> TrackingDirectoryWrapper. IndexWriter should use an instance of this class to
> track those stale files (until the problem is solved).
> I would like to keep FSDirectory clean from this, especially, as this is
> broken anyways: If somebody has another directory impl like HDFS or
> Infinispan, the problem still persists. The base directory should throw an
> IOException if trying to sync a file that does not exist!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
