[
https://issues.apache.org/jira/browse/LUCENE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371008#comment-15371008
]
ASF subversion and git services commented on LUCENE-7373:
---------------------------------------------------------
Commit 3125fccd8dde211567c49a6fe508f80ace3b053b in lucene-solr's branch
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3125fcc ]
LUCENE-7373: remove deprecated API
> Break out Directory.syncMetaData from FSDirectory.renameFile
> ------------------------------------------------------------
>
> Key: LUCENE-7373
> URL: https://issues.apache.org/jira/browse/LUCENE-7373
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7373.patch
>
>
> Today, when you call {{FSDirectory.renameFile}} it also calls fsync on
> the directory.
> This is OK for Lucene's current usage of this method, to rename just
> the one {{segments_N}} file on commit.
> But in playing with adding NRT replication (LUCENE-5438) to the simple
> demo Lucene server (LUCENE-5376) I found that, on spinning disks, that
> fsync is very costly, because when copying over an NRT point, we write
> to N .tmp files and then rename many files (taking seconds) in the
> end.
> I think we should just deprecate/remove the existing method, and make a new
> {{rename}} method that does only renaming, and a separate
> {{syncMetaData}} to call fsync on the directory?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
