[
https://issues.apache.org/jira/browse/HDFS-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844869#comment-13844869
]
Chris Nauroth commented on HDFS-5650:
-------------------------------------
Haohui and I discussed this offline, and I'd like to recap our considerations
here for everyone's benefit.
As initially defined, {{AclReadFlag}} and {{AclWriteFlag}} both had a single
element: {{RECURSIVE}}. My thinking was that these enums would give us an
extension point for implementing some of the additional flags on Linux
getfacl/setfacl at a later date. Examples of these flags include various
filtering options on getfacl and control of the mask recalculation on setfacl.
The getfacl flags don't all make sense in the context of setfacl (and vice
versa), hence the definition of two separate enums for compile-time enforcement.
As Haohui dug into the NameNode implementation, we started to see problems with
this approach:
* A naive implementation of recursive setfacl on the server side could harm the
NameNode. If the namesystem write lock is held while changing a large
sub-tree, then this would block other clients. Even if we periodically release
and reacquire the lock, there is still the problem of consuming an RPC handler
thread.
* It's inconsistent with existing operations like chmod, where the server
doesn't provide the recursion, and instead the higher-level application chooses
whether or not to provide it. For example, FsShell drives recursive chmod from
the client side, and WebHDFS doesn't provide recursive chmod.
* There is a maintenance cost associated with the additional serialization
code. This is particularly awkward for enums, where the protobuf definitions
and translators need updates whenever the enum elements change.
Based on these considerations, I agree with Haohui's proposal. If needed, the
flags can be added back to the API at a later date in a backwards-compatible
way by overloading the methods.
Haohui, I'll review this for you.
> Remove AclReadFlag and AclWriteFlag in FileSystem API
> -----------------------------------------------------
>
> Key: HDFS-5650
> URL: https://issues.apache.org/jira/browse/HDFS-5650
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client, namenode, security
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Attachments: HDFS-5650.000.patch, HDFS-5650.001.patch
>
>
> AclReadFlag and AclWriteFlag intended to capture various options used in
> getfacl and setfacl. These options determine whether the tool should traverse
> the filesystem recursively, follow the symlink, etc., but they are not part
> of the core ACLs abstractions.
> The client program has more information and more flexibility to implement
> these options. This jira proposes to remove these flags to simplify the APIs.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
