[ 
https://issues.apache.org/jira/browse/HDFS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997264#comment-13997264
 ] 

Uma Maheswara Rao G commented on HDFS-2006:
-------------------------------------------

Thanks Nicholas, we will update the details in design doc about the size limit.
{code}
Also, I think we should have different limits for different XAttr namespaces 
(user, trusted, security and system) since we may want to put a smaller limit 
for the user visible namespaces. How does it sound?
{code}

This make sense to me. As in the initial thinking, we will have configuration 
parameter for controlling the size. Now as you pointed, if at all Kernel wants 
use it with a little larger value for some  purpose later, we need to modify 
the single parameter right now, from then it allows users also to write larger 
values. Storing larger values in editlog is not good with any namespace, but it 
will up to kernel implementation decision later.

I am +1 on this consideration.
Let me file a JIRA for it and discuss more about this point if others have any 
concerns.


> 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, HDFS-XAttrs-Design-2.pdf, 
> HDFS-XAttrs-Design-3.pdf, Test-Plan-for-Extended-Attributes-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)

Reply via email to