Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS, mail # dev - Heads up - Snapshots feature merge into trunk


Copy link to this message
-
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.

-Todd
--
Todd Lipcon
Software Engineer, Cloudera