[
https://issues.apache.org/jira/browse/HDFS-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009079#comment-14009079
]
stack commented on HDFS-6109:
-----------------------------
Thanks for the blog post pointer. Pertinent.
Nit: Swap ofer on this if/else + if (!syncBehindWritesInBackground) {
It is harder to read NOT true.
Its a big of a pain running a pool of threads just to do sync_file_range (that
is supposed to be able to run asynchronously -- except it often doesn't as per
the blog posting) but this is better than our having big pauses.
+1 on patch. This facility is off by default and doesn't cost when off. A
test that verifies the executor runs and calls sync_file_range when this
facility is enabled would be a little pedantic IMO. What do others think?
Nice one [~xieliang007]
> let sync_file_range() system call run in background
> ---------------------------------------------------
>
> Key: HDFS-6109
> URL: https://issues.apache.org/jira/browse/HDFS-6109
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: datanode
> Affects Versions: 3.0.0, 2.3.0
> Reporter: Liang Xie
> Assignee: Liang Xie
> Attachments: HDFS-6109.txt
>
>
> Through we passed SYNC_FILE_RANGE_WRITE to sync_file_range, to make it as
> asynchronous as possible, it still could be blocked, e.g. the os io request
> queue is full.
> Since we use sync_file_range just as a page cache advisor role:) it doesn't
> decide or guarantee the real durability, it would be nice if we could run it
> in backgroud. At least my test log showed, a few sync_file_range calls still
> cost tens of ms or more, due to the happened location is in the critical
> write path(BlockReceiver class), from a upper view, like HBase application,
> will "hung" tens of ms as well during Hlog syncing.
> Generally speaking, the patch could not improve too much, but, better than
> before, right ? :)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
