[
https://issues.apache.org/jira/browse/HDFS-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229266#comment-14229266
]
Chris Nauroth commented on HDFS-7454:
-------------------------------------
Last time I checked on this, an {{AclEntry}} could theoretically be represented
as:
* 1 bit for scope (access or default)
* 2 bits for type (user, group, mask or other)
* 3 bits for permission (none, execute, write, write-execute, read,
read-execute, read-write, all)
* 25 bits for name, which is the larger of user and group as represented by
{{INodeWithAdditionalFields#PermissionStatusFormat}}.
* Perhaps 1 additional bit would be necessary to represent whether or not name
is defined at all (essentially to support null).
* That's a total of either 31 or 32 bits depending on if we need the null
indicator.
With that scheme, an {{AclEntry}} fits in a 32-bit Java {{int}}. Using
{{INodeWithAdditionalFields#PermissionStatusFormat}} instead of
{{SerialNumberManager}} keeps it inside an {{int}} instead of requiring a
{{long}}. I believe this would be a safe change for any practical existing
data, but I'd want to think through the edge cases a bit more, and we could
jump to {{long}} if necessary.
However, none of this would address the duplication problem. My earlier RAM
sizing estimates in the HDFS-4685 design document showed that duplication of
the {{AclFeature}} instances and the arrays they contain is a more significant
factor than the size of the array elements. That would indicate there is still
value in what Vinay's patch has done here.
> Implement Global ACL Set for memory optimization in NameNode
> ------------------------------------------------------------
>
> Key: HDFS-7454
> URL: https://issues.apache.org/jira/browse/HDFS-7454
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Reporter: Vinayakumar B
> Assignee: Vinayakumar B
> Attachments: HDFS-7454-001.patch
>
>
> HDFS-5620 indicated a GlobalAclSet containing unique {{AclFeature}} can be
> de-duplicated to save the memory in NameNode. However it was not implemented
> at that time.
> This Jira re-proposes same implementation, along with de-duplication of
> unique {{AclEntry}} across all ACLs.
> One simple usecase is:
> A mapreduce user's home directory with the set of default ACLs, under which
> lot of other files/directories could be created when jobs is run. Here all
> the default ACLs of parent directory will be duplicated till the explicit
> delete of those ACLs. With de-duplication,only one object will be in memory
> for the same Entry across all ACLs of all files/directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)