[
https://issues.apache.org/jira/browse/HDFS-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012627#comment-14012627
]
Colin Patrick McCabe commented on HDFS-6109:
--------------------------------------------
{code}
Index:
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsVolumeImpl.java
===================================================================
---
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsVolumeImpl.java
(revision 1598208)
+++
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/FsVolumeImpl.java
(working copy)
@@ -49,7 +49,7 @@
* It uses the {[~alanlink]FsDatasetImpl} object for synchronization.
*/
@InterfaceAudience.Private
-class FsVolumeImpl implements FsVolumeSpi {
+public class FsVolumeImpl implements FsVolumeSpi {
{code}
I think, rather than exposing the implementation classes and doing typecasts,
we should just add a method to {{FsDatasetSpi}} like
{{submitBackgroundSyncFileRangeRequest}}. Then {{FsDatasetImpl}} can add a
method implementing this, and other implementations can choose to do something
(or nothing) as they like.
Looks good aside from that. It would be nice to see some performance numbers.
> 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-v2.txt, HDFS-6109-v3.txt, 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)
