[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331219#comment-17331219
]
Ayush Saxena commented on HDFS-15624:
-
End result makes sense, The way to do so can be easy. Let us just commit a one
line Addendum to this patch, changing the layout version to 67:
{code:java}
diff --git
a/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeLayoutVersion.java
b/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeLayoutVersion.java
index b2477466be9..0aab66b569c 100644
---
a/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeLayoutVersion.java
+++
b/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeLayoutVersion.java
@@ -90,7 +90,7 @@ public static boolean supports(final LayoutFeature f, final
int lv) {
QUOTA_BY_STORAGE_TYPE(-63, -61, "Support quota for specific storage
types"),
ERASURE_CODING(-64, -61, "Support erasure coding"),
EXPANDED_STRING_TABLE(-65, -61, "Support expanded string table in
fsimage"),
- NVDIMM_SUPPORT(-66, -61, "Support NVDIMM storage type");
+ NVDIMM_SUPPORT(-67, -61, "Support NVDIMM storage type");
private final FeatureInfo info;
{code}
post this commit HDFS-15566 with layout version as 66, Things should get
sorted out.
> Fix the SetQuotaByStorageTypeOp problem after updating hadoop
> ---
>
> Key: HDFS-15624
> URL: https://issues.apache.org/jira/browse/HDFS-15624
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Affects Versions: 3.4.0
>Reporter: YaYun Wang
>Assignee: huangtianhua
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 3.4.0
>
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum
> of StorageType. And, setting the quota by storageType depends on the
> ordinal(), therefore, it may cause the setting of quota to be invalid after
> upgrade.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17329967#comment-17329967 ] Mingliang Liu commented on HDFS-15624: -- Thanks [~weichiu]. I'm fine with your proposal. I hope 3.3.1 released can be unblocked soon. > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.4.0 >Reporter: YaYun Wang >Assignee: huangtianhua >Priority: Major > Labels: pull-request-available, release-blocker > Fix For: 3.4.0 > > Time Spent: 9h 40m > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17329956#comment-17329956 ] Wei-Chiu Chuang commented on HDFS-15624: Hi looks like we have a problem here. I'm going to reopen this issue. For details, please see my discussion thread: https://lists.apache.org/thread.html/rbdd58fda1b528c345713f902c6a659fa1fc8671cbf67f59fc31e25ee%40%3Chdfs-dev.hadoop.apache.org%3E > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.4.0 >Reporter: YaYun Wang >Assignee: huangtianhua >Priority: Major > Labels: pull-request-available, release-blocker > Fix For: 3.4.0 > > Time Spent: 9h 40m > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227101#comment-17227101 ] huangtianhua commented on HDFS-15624: - [~brahmareddy][~vinayakumarb][~ayushtkn] sorry to disturb, would you please to review the code https://github.com/apache/hadoop/pull/2377? Thanks very much. > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.4.0 >Reporter: YaYun Wang >Priority: Major > Labels: pull-request-available, release-blocker > Time Spent: 6.5h > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223698#comment-17223698
]
Brahma Reddy Battula commented on HDFS-15624:
-
{quote}Wanted to check HDFS-15660 too, but now my namenode isn't starting now
because of this, and It will take time to sort it. But I am still convinced it
is different, so no need to hold this, But still I will respect opinions on how
to go ahead.
{quote}
I think, you can post in mailing list others also can try to help you sort out.
{quote}Right now, PR is handling the backward compatibility related issues (due
to change in StorageType order) and inclusion of new Storage policy, by bumping
the LayoutVersion and adding check against NVDIMM releated operations to block
during upgrade.
{quote}
I dn't think bumping the namelayout is best solution, need to check other way.
( may be like checking the client version during the upgrade.)
{quote}HDFS-15660 will be handled soon enough to solve issues of both PROVIDED
and NVDIMM in a generic way.
{quote}
Yes, I too prefer generic way.
{quote}In any case, if not able to fix any of these by the release time (which
I think we still have some time), then we can think of revert.
{quote}
with provided storage we've given couple of releases, there are alternatives to
avoid this.
> Fix the SetQuotaByStorageTypeOp problem after updating hadoop
> ---
>
> Key: HDFS-15624
> URL: https://issues.apache.org/jira/browse/HDFS-15624
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Affects Versions: 3.4.0
>Reporter: YaYun Wang
>Priority: Major
> Labels: pull-request-available, release-blocker
> Time Spent: 6h
> Remaining Estimate: 0h
>
> HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum
> of StorageType. And, setting the quota by storageType depends on the
> ordinal(), therefore, it may cause the setting of quota to be invalid after
> upgrade.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223033#comment-17223033
]
Vinayakumar B commented on HDFS-15624:
--
No need to hold this Jira and No need to revert HDFS-15025 as long as all of
them (including HDFS-15660) lands up before release of 3.4.0.
In any case, if not able to fix any of these by the release time (which I think
we still have some time), then we can think of revert.
Right now, PR is handling the backward compatibility related issues (due to
change in StorageType order) and inclusion of new Storage policy, by bumping
the LayoutVersion and adding check against NVDIMM releated operations to block
during upgrade.
HDFS-15660 will be handled soon enough to solve issues of both PROVIDED and
NVDIMM in a generic way. Right now also, 2.x clients will not be able to talk
3.x namenode via {{getContentSummary()}} or {{getQuotaUsage()}} on directories
with Quota on Storage Types.
> Fix the SetQuotaByStorageTypeOp problem after updating hadoop
> ---
>
> Key: HDFS-15624
> URL: https://issues.apache.org/jira/browse/HDFS-15624
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Reporter: YaYun Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum
> of StorageType. And, setting the quota by storageType depends on the
> ordinal(), therefore, it may cause the setting of quota to be invalid after
> upgrade.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222863#comment-17222863
]
Ayush Saxena commented on HDFS-15624:
-
No, I didn't try. I just saw the code and thought it would be a problem and
folks there at HDFS-15025 confirmed too. I was just bothered it should get
fixed and frankly didn't follow much. (Limited Bandwidth, Saw the code again
today, because [~huangtianhua] asked for)
I just tried, First the upgrade issue, due to the change of ordinal,
{noformat}
ayushsaxena@ayushsaxena-MBP16 hadoop % bin/hdfs dfsadmin -setSpaceQuota 5
-storageType ARCHIVE /dir
2020-10-29 16:14:03,072 WARN util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
ayushsaxena@ayushsaxena-MBP16 hadoop % bin/hdfs dfs -count -q -h -t ARCHIVE /dir
2020-10-29 16:15:43,660 WARN util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
5 5 /dir
ayushsaxena@ayushsaxena-MBP16 hadoop % bin/hdfs dfs -count -q -h -t DISK /dir
2020-10-29 16:15:52,942 WARN util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
none inf /dir
Upgrade Namenode : Magic, Had set quota for ARCHIVE not for DISK
ayushsaxena@ayushsaxena-MBP16 hadoop % bin/hdfs dfs -count -q -h -t DISK /dir
2020-10-29 16:31:39,677 WARN util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
5 5 /dir
ayushsaxena@ayushsaxena-MBP16 hadoop % bin/hdfs dfs -count -q -h -t ARCHIVE /dir
2020-10-29 16:31:48,698 WARN util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
none inf /dir
{noformat}
Now the Rolling Upgrade stuff, I had set quota on Provided before finalising
the upgrade, then Rollback, My NN crashed with :
{noformat}
2020-10-29 16:51:06,261 ERROR org.apache.hadoop.hdfs.server.namenode.FSImage:
Error replaying edit log at offset 25. Expected transaction ID was 9
Recent opcode offsets: 25
java.lang.ArrayIndexOutOfBoundsException: 5
at
org.apache.hadoop.fs.StorageType.parseStorageType(StorageType.java:80)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$SetQuotaByStorageTypeOp.readFields(FSEditLogOp.java:2363)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$LengthPrefixedReader.decodeOp(FSEditLogOp.java:5161)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$Reader.readOp(FSEditLogOp.java:5021)
at
org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.nextOpImpl(EditLogFileInputStream.java:229)
at
org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.nextOp(EditLogFileInputStream.java:276)
at
org.apache.hadoop.hdfs.server.namenode.EditLogInputStream.readOp(EditLogInputStream.java:85)
at
org.apache.hadoop.hdfs.server.namenode.RedundantEditLogInputStream.nextOp(RedundantEditLogInputStream.java:200)
at
org.apache.hadoop.hdfs.server.namenode.EditLogInputStream.readOp(EditLogInputStream.java:85)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.loadEditRecords(FSEditLogLoader.java:243)
at
org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.loadFSEdits(FSEditLogLoader.java:182)
at
org.apache.hadoop.hdfs.server.namenode.FSImage.loadEdits(FSImage.java:914)
at
org.apache.hadoop.hdfs.server.namenode.FSImage.loadFSImage(FSImage.java:761)
at
org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:338)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1197)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:779)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:674)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:761)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:1015)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:988)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1757)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1822)
2020-10-29 16:51:06,263 WARN
org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception
loading fsimage
org.apache.hadoop.hdfs.server.namenode.EditLogInputException: Error replaying
edit log at offset 25. Expected transaction ID was 9
Recent opcode offsets: 25
at
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222805#comment-17222805
]
Brahma Reddy Battula commented on HDFS-15624:
-
{quote}, like the broken FsImage Compatibility, due to change in ordinal of
Storage Types. Rolling Upgrade issue.
{quote}
did you try it..? can you describe which scenario you tried and paste snapshot
before you talk about revert.?
Based on the above
> Fix the SetQuotaByStorageTypeOp problem after updating hadoop
> ---
>
> Key: HDFS-15624
> URL: https://issues.apache.org/jira/browse/HDFS-15624
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Reporter: YaYun Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum
> of StorageType. And, setting the quota by storageType depends on the
> ordinal(), therefore, it may cause the setting of quota to be invalid after
> upgrade.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222654#comment-17222654 ] huangtianhua commented on HDFS-15624: - [~ayushtkn], hi, I agree with you because the code is almost ready, would you please help to review too, https://github.com/apache/hadoop/pull/2377 > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Reporter: YaYun Wang >Priority: Major > Labels: pull-request-available > Time Spent: 4.5h > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1773#comment-1773 ] Ayush Saxena commented on HDFS-15624: - HDFS-15660 is handling a different issue, things getting fixed here are quite specific to NVDMIM, like the broken FsImage Compatibility, due to change in ordinal of Storage Types. Rolling Upgrade issue. Regarding HDFS-15660 : That tends to handle the exception due to missing storage type at Client, and so the protobuf response while decoding the new Storage Type, fetches an exception. This would happen with NVDMIM also, in case of 3.3.0 client and and 3.4.0 server, but that is something not being chased here. No point holding this IMO, I didn't check at what stage the code is now, considering Vinay was following. I think that is almost at conclusion, and we should get this in and sort the mess from HDFS-15025. But I am ok holding it as well, but in that case we should revert HDFS-15025, So, as if this doesn't get concluded for any reasons, later getting rid of this shouldn't be a problem, and even prevent someone backporting the original in there internal versions. [~vinayakumarb]/ [~liuml07] let me know if you folks too want to hold it for HDFS-15660(This won't be too quick and is quite different as well), Will revert the original by tomorrow EOD and we can track there in that case. > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Reporter: YaYun Wang >Priority: Major > Labels: pull-request-available > Time Spent: 4h 10m > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222133#comment-17222133 ] Brahma Reddy Battula commented on HDFS-15624: - there is an issue provided storage type itself ( https://issues.apache.org/jira/browse/HDFS-15660), issue can be addressed there itself > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Reporter: YaYun Wang >Priority: Major > Labels: pull-request-available > Time Spent: 4h > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[ https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212111#comment-17212111 ] huangtianhua commented on HDFS-15624: - [~ayushtkn], thanks very much. We will bump up the NamemodeLayoutVertion to -66 and add validation for related operates with the new storage type nvdimm. > Fix the SetQuotaByStorageTypeOp problem after updating hadoop > --- > > Key: HDFS-15624 > URL: https://issues.apache.org/jira/browse/HDFS-15624 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Reporter: YaYun Wang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum > of StorageType. And, setting the quota by storageType depends on the > ordinal(), therefore, it may cause the setting of quota to be invalid after > upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15624) Fix the SetQuotaByStorageTypeOp problem after updating hadoop
[
https://issues.apache.org/jira/browse/HDFS-15624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17211938#comment-17211938
]
Ayush Saxena commented on HDFS-15624:
-
I think you would need to handle rolling upgrade-downgrade scenario as well and
bump up the {{NamenodeLayoutVersion?}}
> Fix the SetQuotaByStorageTypeOp problem after updating hadoop
> ---
>
> Key: HDFS-15624
> URL: https://issues.apache.org/jira/browse/HDFS-15624
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Reporter: YaYun Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> HDFS-15025 adds a new storage Type NVDIMM, changes the ordinal() of the enum
> of StorageType. And, setting the quota by storageType depends on the
> ordinal(), therefore, it may cause the setting of quota to be invalid after
> upgrade.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
