[
https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977113#comment-13977113
]
Chris Nauroth commented on HDFS-2006:
-------------------------------------
bq. I think any committer can make a branch, so I went ahead and did it:
Thanks for doing this, Andrew. I didn't know I could do this. Now I feel
drunk with power! :-)
bq. This is good point. We will think to integrate later once this work is in?
Yes, I think that's a good plan for initial development. As long as there is
no way for the xattr APIs to "cross over" and touch things related to ACLs,
then there is no risk of circumventing important ACL logic.
bq. This is same like if #hasAcl()
It sounded like you would take a previously unused bit on the inode (or a data
structure referenced from the inode) and start toggling it on to indicate
presence of xattrs. Do I understand correctly? If so, what specific data
structure/field/bit do you have in mind?
Earlier versions of the ACLs design doc described repurposing a previously
unused bit in {{FsPermission}} as a flag to indicate presence of an ACL. We
went through a lot of debate on this and finally decided not to do it.
Instead, discovery of presence of an ACL is accomplished in the ls shell
command via an extra RPC call. This is a trade-off of course, but the
consensus was that this was preferable over implementing the ACL bit and
introducing risk of data consistency bugs (i.e. if we store ACLs in the feature
but forget to toggle on the ACL bit) or unexpected results (i.e. if some legacy
bug accidentally turned on the thing that is now the ACL bit when persisting to
fsimage). The only real need for a {{hasAcl}} kind of method was to support
the ls display of appending '+' to the permission string when an ACL is
present. I'm not aware of any similar requirement on ls for xattrs.
All of the other responses basically make sense to me, and I'll wait for the
next revision of the design document for further comments. I also can
volunteer to help with code reviews on sub-tasks. Thank you for the replies!
> ability to support storing extended attributes per file
> -------------------------------------------------------
>
> Key: HDFS-2006
> URL: https://issues.apache.org/jira/browse/HDFS-2006
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: HDFS XAttrs (HDFS-2006)
> Reporter: dhruba borthakur
> Assignee: Yi Liu
> Attachments: HDFS-XAttrs-Design-1.pdf, xattrs.1.patch, xattrs.patch
>
>
> It would be nice if HDFS provides a feature to store extended attributes for
> files, similar to the one described here:
> http://en.wikipedia.org/wiki/Extended_file_attributes.
> The challenge is that it has to be done in such a way that a site not using
> this feature does not waste precious memory resources in the namenode.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
