hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uma Maheswara Rao G (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (HDFS-2006) ability to support storing extended attributes per file
Date Wed, 23 Apr 2014 14:56:28 GMT

     [ https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uma Maheswara Rao G updated HDFS-2006:
--------------------------------------

    Comment: was deleted

(was: [~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)

Mime
View raw message