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. Tsz-Wo ________________________________ From: Aaron T. Myers <a...@cloudera.com> To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; Tsz Wo Sze <szets...@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 <szets...@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
