Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Sat, 13 Apr 2013 00:26:15 +0000 (UTC)
From: "Jing Zhao (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12641502.1365470133683.161092.1365812775891@arcas>
In-Reply-To: <JIRA.12641502.1365470133683@arcas>
References: <JIRA.12641502.1365470133683@arcas>
Subject: [jira] [Updated] (HDFS-4675) Fix rename across snapshottable
 directories
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jing Zhao updated HDFS-4675:
----------------------------

    Attachment: HDFS-4675.004.patch

Update the patch based on Nicholas's offline comments:
"- INodeReference.dstSnapshot is only used by anonymous references but not WithCount and WithName. So how about changing INodeReference to abstract and adding a new subclass, say
INodeReference.Anonymous/INodeReference.WithSnapshot, for the anonymous references?

- dstSnapshot should be an int, i.e. the id of the snapshot. Otherwise, the fsimage loading won't work.  If the snapshot is deleted, the snapshot object will not be found in the snapshotMap.

- Is toSaveSubtree the same as firstReferred?  We can check it by checking whether the referenceMap contains the inode id as a key.
Then, we don't need to add dirMap.

- Some changes in INodeFileWithSnapshot,
INodeFileUnderConstructionWithSnapshot and INodeDirectoryWithSnapshot are repeated.  Let's create some utility methods."

Also fix another bug when a snapshot deletion operation hits a reference node in the deleted list.
                
> Fix rename across snapshottable directories
> -------------------------------------------
>
>                 Key: HDFS-4675
>                 URL: https://issues.apache.org/jira/browse/HDFS-4675
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: datanode, namenode
>            Reporter: Jing Zhao
>            Assignee: Jing Zhao
>         Attachments: HDFS-4675.000.patch, HDFS-4675.001.patch, HDFS-4675.002.patch, HDFS-4675.002.patch, HDFS-4675.003.patch, HDFS-4675.004.patch
>
>
> For rename across snapshottable directories, suppose there are two snapshottable directories: /user1 and /user2 and we have the following steps:
> 1. Take snapshot s1 on /user1 at time t1.
> 2. Take snapshot s2 on /user2 at time t2.
> 3. Take snapshot s3 on /user1 at time t3.
> 4. Rename /user2/foo/ (an INodeDirectoryWithSnapshot instance) to /user1/foo/.
> After the rename we update the subtree of /user1/foo/ again (e.g., delete /user1/foo/bar), we need to decide where to record the diff. The problem is that the current implementation will identify s3 as the latest snapshot, thus recording the snapshot copy of bar to s3. However, the parent of bar, /user1/foo, is still in the created list of s3. Thus here we should record the snapshot copy of bar to s2.
> If we further take snapshot s4 on /user1, and make some further change under /user1/foo, these changes will be recorded in s4. Then if we delete the snapshot s4, similar with above, we should merge the change to s2, not s3.
> Thus in general, we may need to record the latest snapshots of both the src/dst subtree in the renamed inode and update the current INodeDirectory#getExistingINodeInPath accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira