[
https://issues.apache.org/jira/browse/HDFS-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977079#comment-13977079
]
Jing Zhao commented on HDFS-6266:
---------------------------------
Thanks for the comments, [~daryn].
bq. how is a deleted file inode that belongs to multiple snapshots handled?
The current patch uses the latest snapshot in the path. For e.g., suppose we
have created snapshots s1, s2, and s3 for directory /foo. If we create file
/foo/bar after s1 but before s2, and delete bar after s3, bar now belongs to
snapshot s2 and s3, and the inode for bar is stored in the deleted list of s3.
The current patch will return /foo/.snapshot/s3/bar as the full path for bar.
If we later delete snapshot s3, /foo/.snapshot/s2/bar will be returned.
bq. Is the need for this patch due to loss of the original array of inodes
found during path resolution?
The main use case for this patch currently is for snapshot diff report. The
current snapshot diff report functionality cannot identify "rename". For a
renamed file/directory, we can use information stored in INodeReference to find
the target inode in the rename operation. Then we can use this patch to
identify the full path of the inode and show it in the diff report.
> Identify full path for a given INode
> ------------------------------------
>
> Key: HDFS-6266
> URL: https://issues.apache.org/jira/browse/HDFS-6266
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: snapshots
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Attachments: HDFS-6266.000.patch
>
>
> Currently when identifying the full path of a given inode,
> FSDirectory#getPathComponents and FSDirectory#getFullPathName can only handle
> normal cases where the inode and its ancestors are not in any snapshot. This
> jira aims to provide support to handle snapshots. This can be useful for
> identifying the "Rename" change in a snapshot diff report.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
