[
https://issues.apache.org/jira/browse/HDFS-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510231#comment-13510231
]
Colin Patrick McCabe commented on HDFS-4103:
--------------------------------------------
* If objects of type {{INodeDirectorySnapshottable}} cannot be deleted,
{{collectSubtreeBlocksAndClear}} method does not apply to them. We should
override that method to throw an exception for this type.
{code}
/** Modify an inode in current state. */
void modify(final INode oldinode, final INode newinode) {
if (!oldinode.equals(newinode)) {
throw new AssertionError("The names do not match: oldinode="
+ oldinode + ", newinode=" + newinode);
}
final int c = search(created, newinode);
if (c >= 0) {
// inode is already in c-list,
created.set(c, newinode);
} else {
final int d = search(deleted, oldinode);
if (d < 0) {
// neither in c-list nor d-list
insertCreated(newinode, c);
insertDeleted(oldinode, d);
}
}
}
{code}
This wasn't changed by this patch, but should we throw an exception here if c <
0 && d >= 0?
{code}
@Override
+ public INodeSymlink clone() {
+ return new INodeSymlink(this);
+ }
{code}
The {{Cloneable}} interface in Java is problematic. If you don't implement a
clone method, Java creates one for you-- one which shallow-copies all fields.
For example, try commenting out your new clone method. The code continues to
compile-- but does the wrong thing, because now you're implicitly using the
default clone method.
I think it might make more sense to call this method {{createClone}} or
something like that, and get rid of the {{\@Override}}.
> Support O(1) snapshot creation
> ------------------------------
>
> Key: HDFS-4103
> URL: https://issues.apache.org/jira/browse/HDFS-4103
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: Snapshot (HDFS-2802)
> Reporter: Tsz Wo (Nicholas), SZE
> Assignee: Tsz Wo (Nicholas), SZE
> Attachments: h4103_20121129.patch, h4103_20121202b.patch,
> h4103_20121202.patch
>
>
> In our first snapshot implementation, snapshot creation runs in O(N) and
> occupies O(N) memory space, where N = # files + # directories + # symlinks in
> the snapshot. The advantages of the implementation are that there is no
> additional cost for the modifications after snapshots are created, and it
> leads to a simple implementation.
> In this JIRA, we optimize snapshot creation to O(1) although it introduces
> additional cost in the modifications after snapshots are created. Note that
> the INode is given as an assumption, otherwise, there is a non-constant cost
> to find the INode.
--
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
