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

Jing Zhao created HDFS-4675:
-------------------------------

             Summary: Fix rename across snapshottable directories
                 Key: HDFS-4675
                 URL: https://issues.apache.org/jira/browse/HDFS-4675
             Project: Hadoop HDFS
          Issue Type: Sub-task
            Reporter: Jing Zhao
            Assignee: Jing Zhao


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