Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Fri, 6 Jun 2014 01:22:01 +0000 (UTC)
From: "Yi Liu (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12718730.1402004987979.79757.1402017721745@arcas>
In-Reply-To: <JIRA.12718730.1402004987979@arcas>
References: <JIRA.12718730.1402004987979@arcas>
Subject: [jira] [Commented] (HDFS-6492) Support create-time xattrs and
 atomically setting multiple xattrs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yi Liu commented on HDFS-6492:
------------------------------

Thanks Andrew, I agree with you.
{quote}
 It'd be better to not do this as separate edit log ops, since it means we need to deal with a file with no xattrs, or just a key but no IV. Thus, create/mkdir time xattrs.
{quote}
You mean not do this as separate edit log ops? Combined into create/mkdir?
 I think even with separate edit log, we don't need to do additional things. Existing implementation can cover it automatically, we just need to invoke FSDirectory#setXAttr in HDFS core.

> Support create-time xattrs and atomically setting multiple xattrs
> -----------------------------------------------------------------
>
>                 Key: HDFS-6492
>                 URL: https://issues.apache.org/jira/browse/HDFS-6492
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>    Affects Versions: 3.0.0
>            Reporter: Andrew Wang
>            Assignee: Andrew Wang
>
> Ongoing work in HDFS-6134 requires being able to set system namespace extended attributes at create and mkdir time, as well as being able to atomically set multiple xattrs at once. There's currently no need to expose this functionality in the client API, so let's not unless we have to.


--
This message was sent by Atlassian JIRA
(v6.2#6252)