Suresh Srinivas 2013-04-13, 01:05
Aaron T. Myers 2013-04-18, 01:45
Tsz Wo Sze 2013-04-18, 18:48
Aaron T. Myers 2013-04-18, 20:49
Tsz Wo Sze 2013-04-18, 21:53
Aaron T. Myers 2013-04-18, 22:06
-Re: Heads up - Snapshots feature merge into trunk
Todd Lipcon 2013-04-24, 20:25
On Fri, Apr 19, 2013 at 3:36 AM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 19, 2013 at 6:53 AM, Tsz Wo Sze <[EMAIL PROTECTED]> wrote:
> > HdfsAdmin is also for admin operations. However, createSnapshot etc
> > methods aren't.
> I agree that they're not administrative operations in the sense that they
> don't strictly require super user privilege, but they are "administrative"
> in the sense that they will most-often be used by those administering HDFS.
> The HdfsAdmin class should not be construed to contain only operations
> which require super user privilege, even though that happens to be the case
> right now. It's intended as just a public API for HDFS-specific operations.
> Regardless, my point is not necessarily that these operations should go
> into the HdfsAdmin class, but rather that they shouldn't go into the
> FileSystem class, since the snapshots API doesn't seem to me like it will
> generalize to other FileSystem implementations.
Agreed. The cases of WAFL/ZFS were brought up -- in those file systems,
even if users may take snapshots, they're done using FS-specific APIs
rather than any standard Linux interface. So, I'm in favor of either
putting the APIs in HdfsAdmin, or alternatively in DistributedFileSystem,
forcing a user to down-cast if they want to use the HDFS-specific operation.
Software Engineer, Cloudera
Suresh Srinivas 2013-04-24, 21:00