[
https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040357#comment-13040357
]
dhruba borthakur commented on HDFS-2006:
----------------------------------------
@Konstantin: This feature can be used in a very generic fashion to store file
attributes: one can build ACL style permissions,
per-file-block-placement-policies, etc.etc.
@Aaron: The block-to-file ratio is not big, so we need to manage memory usage
on the namenode very carefully.
@Matt: It would be fine for the clients to do another disk access to read the
extended attributes. The overall thinking I have in mind is somewhat like this:
the NN stores the location of the extended attribute. This location can
znode-identifier or a generic URL, let's call it the attributeURL. The
HDFS-client makes a call to the NN to fetch the attributeURL and then directly
accesses the attribute contents. If we limit the length of the attributeURL,
then the NN can possibly cache it in memory.
> 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: name-node
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
>
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
