[
https://issues.apache.org/jira/browse/HDFS-15025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202476#comment-17202476
]
Mingliang Liu edited comment on HDFS-15025 at 9/26/20, 1:07 AM:
----------------------------------------------------------------
[~ayushtkn] This is a good question.
First, I did not see code that depends on the ordinal of the enums, given users
configure disks with storage name and set the storage policy for directories.
The existing disk type names and storage polices kept their name and ordinal.
So I was not thinking this was a "Incompatible" change - even it adds new
fields ({{isRam}}) to this class. Meanwhile, in the code comment, it says the
type is sorted by speed, not fixed ordinal.
{code}
@InterfaceStability.Unstable
public enum StorageType {
// sorted by the speed of the storage types, from fast to slow
{code}
Second, I was not aware of the test failure in multiple previous QA runs of the
patch (in the pull request). I did not check the last QA run, but would be glad
if we can find out why this was not reported in PreCommit runs. [~wangyayun]
Would have a look the test failure and/or why it was not reported previously? I
glimpsed and now think the test just because it makes assumptions about the
ordinal - which makes sense as the {{quote}} array was covering complete types
previously. I think your proposal works great and fixes the test, so +1 on the
idea to fix.
CC: [~brahmareddy]
was (Author: liuml07):
[~ayushtkn] This is good question.
First, I did not see code that depends on the ordinal of the enums, given users
configure disks with storage name and set the storage policy for directories.
The existing disk type names and storage polices kept their name and ordinal.
So I was not thinking this was a "Incompatible" change - even it adds new
fields ({{isRam}}) to this class. Meanwhile, in the code comment, it says the
type is sorted by speed, not fixed ordinal.
{code}
@InterfaceStability.Unstable
public enum StorageType {
// sorted by the speed of the storage types, from fast to slow
{code}
Second, I was not aware of the test failure in multiple previous QA runs of the
patch (in the pull request). I did not check the last QA run, but would be glad
if we can find out why this was not reported in PreCommit runs. [~wangyayun]
Would have a look? I glimpsed and think the test just because it makes
assumptions about the ordinal. I think your proposal works just fine and fixes
the test, so +1 on the idea.
CC: [~brahmareddy]
> Applying NVDIMM storage media to HDFS
> -------------------------------------
>
> Key: HDFS-15025
> URL: https://issues.apache.org/jira/browse/HDFS-15025
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: datanode, hdfs
> Reporter: YaYun Wang
> Assignee: YaYun Wang
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.4.0
>
> Attachments: Applying NVDIMM to HDFS.pdf, HDFS-15025.001.patch,
> HDFS-15025.002.patch, HDFS-15025.003.patch, HDFS-15025.004.patch,
> HDFS-15025.005.patch, HDFS-15025.006.patch, NVDIMM_patch(WIP).patch
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> The non-volatile memory NVDIMM is faster than SSD, it can be used
> simultaneously with RAM, DISK, SSD. The data of HDFS stored directly on
> NVDIMM can not only improves the response rate of HDFS, but also ensure the
> reliability of the data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
