[
https://issues.apache.org/jira/browse/HDFS-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906523#comment-16906523
]
Eric Yang commented on HDFS-2470:
---------------------------------
Thank you [~swagle] for the patch. Namenode directory is created with 700
permssion, however, I think there are still bugs in the implementation. A few
questions about patch 006:
in
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/common/Storage.java:
{code}
+ if (permission != null) {
+ Set<PosixFilePermission> permissions = EnumSet.of(OWNER_READ,
+ OWNER_WRITE, OWNER_EXECUTE);
+ Files.setPosixFilePermissions(root.toPath(), permissions);
+ Files.setPosixFilePermissions(curDir.toPath(), permissions);
+ }
{code}
# It looks like if permission variable is passed in, it will use hard coded
"permissions". This logic doesn't seem right. I think you want to map the
numeric values of permission variable to PosixFilePermission posix enums.
# Can we avoid passing null as parameters to StorageDirectory method? If it
has not been defined, would it be possible to compute the default permission
(dfs.*.storage.dir.perm) from dirType?
> NN should automatically set permissions on dfs.namenode.*.dir
> -------------------------------------------------------------
>
> Key: HDFS-2470
> URL: https://issues.apache.org/jira/browse/HDFS-2470
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.0-alpha
> Reporter: Aaron T. Myers
> Assignee: Siddharth Wagle
> Priority: Major
> Attachments: HDFS-2470.01.patch, HDFS-2470.02.patch,
> HDFS-2470.03.patch, HDFS-2470.04.patch, HDFS-2470.05.patch, HDFS-2470.06.patch
>
>
> Much as the DN currently sets the correct permissions for the
> dfs.datanode.data.dir, the NN should do the same for the
> dfs.namenode.(name|edit).dir.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
