[
https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978122#comment-13978122
]
Yi Liu commented on HDFS-2006:
------------------------------
[~cnauroth], thanks for the comments.
{quote}
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.
{quote}
Right.
{quote}
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.
{quote}
“Whether inode has a XAttr is through a bit of int which is shared in inode” is
only for phase of loading FSImage.
The “hasXAttrs” is INodeSection.INodeFile#hasXAttrs, and only used when load
FSImage. XAttrFeature is attached to an inode only if that inode has a XAttr.
I will revise the doc to make it clear.
{quote}
I also can volunteer to help with code reviews on sub-tasks. Thank you for the
replies!
{quote}
That would be great, very appreciate.
The patches have been updated in sub-JIRAs, and Deign doc will be updated
tomorrow.
> 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)
