[ https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978118#comment-13978118 ]
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. {quota} “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. {quota} 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)