hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsz Wo Sze <szets...@yahoo.com>
Subject Re: Heads up - Snapshots feature merge into trunk
Date Thu, 18 Apr 2013 21:53:56 GMT
Hi Aaron,

You are right the arguments should be Path but not String.  Will fix it.

HdfsAdmin is also for admin operations.  However, createSnapshot etc methods aren't.


 From: Aaron T. Myers <atm@cloudera.com>
To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; Tsz Wo Sze <szetszwo@yahoo.com>

Sent: Thursday, April 18, 2013 1:49 PM
Subject: Re: Heads up - Snapshots feature merge into trunk

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,

  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