[
https://issues.apache.org/jira/browse/HDFS-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhao updated HDFS-4167:
----------------------------
Attachment: HDFS-4167.004.patch
Rebase the patch and address Nicholas's comments.
bq. It seems that the implementation does not support restoring a deleted file.
In ZFS, the restore can only happen in existing ZFS components like clones,
file systems, snapshots, and volumes. Users cannot directly restore a deleted
file/dir. Thus my current patch checks if the target path is for an existing
file/dir. I think if the user wants to restore a deleted file, she/he can
restore the parent directory or simply copy the file out.
In the meanwhile, to support restoring a deleted file/dir may make the restore
semantic more complicated. For example, suppose we have /foo/bar/file. If the
directory /foo/bar was deleted after snapshot s1, and then a user wants to
restore /foo/.snapshot/s1/bar/file, it is hard to determine where we should put
the file. Also the filesystem API must be defined as you suggested in the jira.
However, the relative path may seem confusing since users usually use relative
path against the working directory of the file system.
bq. Sure, let's make it as a metadata only operation and handle truncate later.
Yeah, we may also use HDFS-3107 to continue the discussion on truncate.
> Add support for restoring/rolling back to a snapshot
> ----------------------------------------------------
>
> Key: HDFS-4167
> URL: https://issues.apache.org/jira/browse/HDFS-4167
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Reporter: Suresh Srinivas
> Assignee: Jing Zhao
> Attachments: HDFS-4167.000.patch, HDFS-4167.001.patch,
> HDFS-4167.002.patch, HDFS-4167.003.patch, HDFS-4167.004.patch
>
>
> This jira tracks work related to restoring a directory/file to a snapshot.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
