Andrew, There are a few differences in the design:
1. It is not a separate filesystem implementation like Giraffa. User sees hdfs://, and uses the same DFSClient. 2. There is no NamespaceAgent exposed to the client. DFClient talks the same NamenodeProtocol. 3. If one is happy with the current in-memory, in-process namespace, it can be used with a simple configuration variable. 4. One could mix and match block management and namespace implementations, rather than mandating a single store for both. Caveat: My knowledge of Giraffa is limited to a few presentations I have seen from Konst, and some discussions about it with folks. Right now, we are facing a few issues in HBase, and have suspended that work, so have not made a decision whether it will be part of the first drop. In any case, the difference namespace implementations need not be part of HDFS patch, but can be hosted separately. - Milind -----Original Message----- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Saturday, October 05, 2013 11:23 AM To: hdfs-dev@hadoop.apache.org Subject: Re: [Proposal] Pluggable Namespace On Thu, Oct 3, 2013 at 12:17 PM, Milind Bhandarkar < mbhandar...@gopivotal.com> wrote: > To get started, we have implemented the same memory-based namespace > implementation in a remote process, outside of the namenode JVM. In > addition, work is undergoing to implement the namesystem using HBase. > This sounds really interesting. I'm curious how similar the HBase part of this work is to Giraffa and if that would be part of an initial drop? -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
