hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: Heads up - Snapshots feature merge into trunk
Date Thu, 18 Apr 2013 20:49:23 GMT
On Fri, Apr 19, 2013 at 4:48 AM, Tsz Wo Sze <szetszwo@yahoo.com> wrote:

> Currently, allowSnapshot(..) and disallowSnapshot(..) are already in
> HdfsAdmin.

Ah, my bad. Not sure how I missed those. Good to see. Though, now that I
look at them, those methods should really be taking Paths as arguments, not
Strings. This is obviously quite minor, though.

>   The other operations createSnapshot(..), renameSnapshot(..) and
> deleteSnapshot(..) are actually user operations and they are declared in
> FileSystem.  Users can take snapshots for their own directories once admin
> has allowed snapshots for those directories.  Snapshot is not a
> HDFS-specific operation.  Many other file systems do support it.  No?

Certainly other "file systems" support it, e.g. WAFL, ZFS, etc, but do
other "FileSystem" (the Hadoop class) implementations, e.g.
LocalFileSystem, S3FileSystem, etc? Will they ever? If they do, will they
support sub-tree snapshots like HDFS does? Snapshots in general seem like
something whose implementation, interface, etc. are highly file
system-specific, and thus I don't think it makes a ton of sense to put that
API in what is intended to be a broad, stable interface. If we were to move
these operations into the HdfsAdmin interface, there's nothing to stop
users from using that interface instead of FileSystem. After all, that was
the point of adding the HdfsAdmin class in the first place - to have a
public API for performing HDFS-specific operations.

Aaron T. Myers
Software Engineer, Cloudera

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message