hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2802) Support for RW/RO snapshots in HDFS
Date Thu, 01 Nov 2012 06:01:22 GMT

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

Aaron T. Myers commented on HDFS-2802:
--------------------------------------

Hi Suresh, I've now had some more time to examine the document, and I have a few questions/comments:

# Regarding the ownership requirement for users to create snapshot - this answers my question
above regarding what would happen when a user tries to create a snapshot of a subtree where
the user doesn't have read access to all the files. But, why not decouple it completely from
Unix permissions? They really have nothing to do with each other now. Perhaps we should just
make a snapshottable directory have a list of users that are allowed to create snapshots of
it?
# Related to the above, the document shows that deleting a snapshot consists of just using
the FSShell to delete it. The document also says that even though a non super-user may create
a snapshot for a given snapshottable directory, files under that directory that the user cannot
read will continue to not be readable in the snapshot. Doesn't this imply that the user may
not be able to delete a snapshot the user has just created? If so, I find the asymmetry between
being able to create a snapshot, but not necessarily delete that snapshot, a little odd. I
think it'd be better to have a deleteSnapshot administrative command to correspond to the
createSnapshot command.
# Rename only within snapshottable directory - I don't see why this limitation is necessary
or desirable. I see that the doc says "This can be revisited" but I'd really like to know
why this restriction is proposed at all.
# Any other use for the linked list (INodeFileWithLink) besides determining the max replicaiton
factor? The document says that this is one of the uses, but I don't see any other uses mentioned.
# You mentioned to Konstantin that the design supports nested snapshots, but I don't see any
discussion of it in the document. My apologies if I missed this.
# Regarding open question #2 - I think that the values of the permission, atime, mtime, etc.
attributes should definitely _not_ change when the attributes of the original file changes.
That should be part of the guarantee of a snapshot. In fact, I believe this open question
is already answered by the #2 and #3 "Operations Supported on Snapshots". I do think it may
make sense to treat the replication factor separately from this, however. Is this what you
were referring to when you said "...if we decide snapshot of file does not preserve the replication
factor at the time of snapshot"?
                
> Support for RW/RO snapshots in HDFS
> -----------------------------------
>
>                 Key: HDFS-2802
>                 URL: https://issues.apache.org/jira/browse/HDFS-2802
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: data-node, name-node
>            Reporter: Hari Mankude
>            Assignee: Hari Mankude
>         Attachments: HDFSSnapshotsDesign.pdf, snap.patch, snapshot-design.pdf, snapshot-design.tex,
snapshot-one-pager.pdf, Snapshots20121018.pdf, Snapshots20121030.pdf
>
>
> Snapshots are point in time images of parts of the filesystem or the entire filesystem.
Snapshots can be a read-only or a read-write point in time copy of the filesystem. There are
several use cases for snapshots in HDFS. I will post a detailed write-up soon with with more
information.

--
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

Mime
View raw message