作者：Konstantin Shvachko 2010-4
原文：http://www.aosabook.org/en/hdfs.html
译者：phylips@bmy 2011-9-17
译文：http://duanple.blog.163.com/blog/static/70971767201181745539637/
[
序：如果说The Hadoop Distributed File System对应了GFS，那么这篇实际上有些与Case Study GFS: Evolution on Fast-forward相似，只是更专注于可扩展性。本文除了提供了关于HDFS可扩展性的各方面的深入思考外，其中使用的估算方法，测试方法及关于可扩展性的思考方法也是非常值得的。
Konstantin V. Shvachko是Yahoo!的HDFS核心开发工程师。致力于面向大规模分布式存储系统的数据结构和算法方面的研究。他发明了一种新型的平衡树—S-trees，用于优化非结构化数据的索引，同时他也是一个基于S-tree的Linux文件系统：treeFS的主要开发者，treeFS是reiserFS的一个原型实现。Konstantin在俄罗斯莫斯科大学获得了计算机科学博士学位。同时他也是Apache Hadoop项目管理委员会成员。
HDFS是一个用于大规模数据处理的开源系统。本文基于在当前最大规模的HDFS部署集群上的经验，对一个单个名字空间服务器的RAM存储空间与Hadoop集群的存储能力之间的关系进行了分析，简单描述了下单节点名字空间服务器的线性性能可扩展性，同时指出了该架构实际存在的一些限制。这些研究结果可以用于其他类似的分布式文件系统中。
]
根据软件演化的标准来看，Hadoop还是一个很年青的项目。在2005年，受Google两篇论文(GFS和MapReduce)的影响，Doug Cutting和Mike Cafarella实现了Hadoop的核心模块。它被广泛接受和快速增长是在2006开始的，那时Yahoo!开始对它的开发进行投资并将Hadoop用作内部的分布式平台。在过去的几年里，Hadoop安装已经从少数几个节点扩展到数千个。现在它已广泛应用于世界各地的很多组织中。
在2006年，那时关于存储的流行词还是Exabyte(1 Exabyte=1000PB)，Yahoo!的Hadoop小组已经开始为Hadoop分布式文件系统规划更长远的目标需求，同时列出了一系列将这些需求变成现实的工程项目。很明显，那时的很多想法现在已经变成了现实，而一个对于基于分布式计算框架如Hadoop MapReduce上的大规模分布式存储系统的需求日益迫切。
时至今日，关于存储的流行词已经变成了Zettabyte(1 Zettabyte=1000Exabyte)，是时候去回顾一下那些目标，分析下现在有那些已经实现了，大胆展望下我们未来关于存储的需求和演化，对比下相比其他系统的优势，以及对于未来的增长可能存在的一些限制。
关于HDFS的四个维度的可扩展性需求可以用如下公式说明：
10PB存储容量×10,000节点数×100,000,000文件数×100,000客户端
最大的Hadoop集群，比如Yahoo!最近用来进行记录排序的一个集群，由4000个节点组成，总的存储容量有14PB。大部分生产集群运行在提供了9PB存储空间的3000个节点上。
Hadoop集群目前已经可以通过单个名字空间服务器处理超过100million的对象，提供100million文件的存储能力。4000节点集群也已能成功地运行具有超过14000个tasks的jobs，并发地对HDFS进行读取和写入。
表1对设定的目标和当前已达到的那些进行了对比
目前的情况是，我们已经实现了petabytes目标，同时已经接近于文件数方面的目标，但是这是在具有小规模节点(4000 Nodes)情况下达到的，同时对于100,000 clients的支持也还没有实现。
目前的问题是，需要确认在当前的系统架构下实现这些目标是否是可行的。主要需要关注的就是单名字空间服务器这一架构。本文研究了下这一架构对HDFS的可扩展性和性能带来的限制。在进行这项工作中所采用的方法对于研究其他类似架构的分布式系统也是很有用的。该研究基于在今天部署的最大规模的Hadoop集群上的经验。性能benchmarks运行在真实集群上，同时关于存储容量的各种估计也是经过了来自生产系统的实际测量结果的验证。
HDFS一瞥
除作为Hadoop 核心模块的一部分及为Hadoop MapReduce提供数据存储层服务，HDFS同时也是一个独立的分布式文件系统，与Lustre，GFS，PVFS，Panasas，GPFS，Ceph和其他的文件系统一样。HDFS专注于系统的总体吞吐量而不是单个操作延迟，专门针对批处理进行了优化。
与大多数现在的分布式文件系统一样，HDFS基于一种名字空间与数据分离的架构。名字空间组成了文件系统元数据，由一个叫做NameNode专用节点维护。数据本身驻留在其他叫做DataNode的节点上。
文件系统数据可以通过HDFS clients访问，客户端会首先联系NameNode获取数据位置信息，然后数据传输到指定的DataNode或者从其中读取(见图1)。
将名字空间与数据分离的主要目的是为了系统的可扩展性。元数据操作通常都是很快的，然而数据传输可能要持续很长时间。如果两个操作都需要通过一个单一的服务器(如NFS那样)，数据传输就会受限于服务器的响应时间，这使得它会成为一个高度分布式的环境中的一个瓶颈。
在分离的架构中，来自多个客户端的快速的元数据操作可以交给名字空间服务器完成，数据传输则直接分布到数据服务器以利用起整个集群的吞吐率。
名字空间由文件和目录组成。目录定义了名字空间的一个层次化结构。文件作为数据的容器，被划分成了很多个blocks(每个128MB)。
NameNode的元数据由层次化的名字空间和block到DataNode的映射关系组成。NameNode会将名字空间映像(image)和它的修改日志(journal)存放在外部存储中，比如是一个本地或者远程磁盘。
名字空间映像和修改日志包含了HDFS文件和目录名称和它们的属性(修改和访问时间，权限，quotas)，包含了组成文件的block IDs，但是不包含blocks的位置信息。位置信息是在启动时由DataNode通过block report进行报告的，之后默认每一小时更新一次。
如果NameNode fail了，它的最新状态可以通过读取名字空间映像和重放修改日志来恢复。
名字空间的限制
HDFS构建于这种单节点名字空间服务器架构之上。
因为NameNode是文件系统元数据的唯一容器，自然地它会成为文件系统增长的一个限制因素。为了使得元数据操作的快速，NameNode会将整个名字空间load到内存中，因此名字空间大小就受限于NameNode可用的RAM大小。
文献[12]的结果表明NameNode会使用不到200个bytes来存储一个元数据对象(一个文件inode或者一个block)。根据在我们集群之上的统计信息，一个文件平均包含1.5个blocks，这就意味着平均每个文件会占掉节点RAM的600个bytes(1个文件对象+2个block对象)。这个估算结果没有包含那些NameNode创建用来进行blocks的创建、复制和删除的中间数据结构etc.在完成后，这些中间数据结构会被删除。
结论1
如果
n ObjSize代表元数据对象大小
n λ代表文件对block的平均比率{!即单个文件由多少个blocks组成}
n F代表总的文件数
那么名字空间服务器的内存占用将最少会是
RAM >= F*ceil(1+λ)*objSize
特别地，为存储100million的文件(会产生200million的blocks)一个NameNode需要有至少60GB(10^8*600)大小的RAM。这个结果与我们实际部署的集群是一致的。
Replication
HDFS是设计运行于不可靠硬件之上的。在Yahoo长期运行的集群上，每天大概每1000节点中内能够观察到2-3个节点的失效。对于新(最近出厂的)节点来说，这个比率还要高三倍。
为了提高数据可靠性，HDFS使用了replication。开始时，每个block被客户端复制到三个DataNode上。Block的这些拷贝称为replicas。系统的默认副本数是3，也可以在每个文件创建时进行指定。
一旦block创建出来，它的replication就是由系统自动维护的了。NameNode会检测失效的DataNodes，replicas的丢失和损坏，并通过将目前存在的replicas拷贝到其他节点进行恢复。
Replication是最简单的数据恢复技术。其他的一些技术，比如冗余的块分割(redundant block striping){!参考RAID0，里面就采用了striping}或者是erasure编码，也是可以使用的，而且已经被其他的一些分布式文件系统比如GPFS，PVFS，Lustre和Panasas所使用。这些方法，尽管在空间上是很高效的(节省存储空间)，但也在数据恢复中引入了一些性能开销。对于striping来说，根据冗余度需求，系统可能需要从它分割的多个节点中读取剩余的2个或者多个剩余的数据段，来重构数据。而Replication总是只需要一份拷贝。
对于HDFS来说，Replication技术的最大优势在于，它提供了具有高可用性的数据。这点也可以有效地被MapReduce框架利用，比如它可以在多个tasks同时访问同一个文件时，通过增加配置文件和job libaray文件的副本数来避免job启动时的竞争。
每个block副本在DataNode上是使用一个本地(本地文件系统的)文件来表示。文件大小等于该block的实际大小，同时不需要额外的空间来使它调整到最大的block大小，这点与传统文件系统不同。因此如果一个block只有10MB大小，那么它就只需要本地文件系统的10MB空间来进行存储。可能需要额外的一点开销，因为HDFS也会为每个block副本存储另一个小的元数据文件，该文件包含了该block数据的校验和。
Replication对于可用性和可靠性都是非常重要的。默认的副本数3，看起来对于大规模的忙碌的集群，大多数情况下也都是合理的。
存储容量VS.名字空间大小
如果100millon的文件平均每个有1.5个blocks，我们将会在文件系统中有200million个blocks。如果最大的block大小是128MB，同时每个block有3个副本，这样存储这些blocks的整个磁盘空间将接近60PB。
结论2
如果
n blockSize代表block最大大小
n r代表block平均副本数
n λ代表文件对block的平均比率{!即单个文件由多少个blocks组成}
n F代表总文件数
那么名字空间所具有的存储容量(SC)将不会超过：
SC <= F*λ*r*blockSize
通过比较结论1和结论2，我们得到如下规律：
RULE1
一般说来，RAM中的名字空间元数据与它所需要的用于数据存储的物理存储空间，有如下关系：
1GB元数据≈1PB物理存储
不能将这个规律等同于像毕达哥拉斯那样的普适性定理，因为它还依赖于集群本身的一些参数，比如文件对block的平均比率，block大小，但是可以将它用于集群资源配置实践中。
集群size与node资源
使用结论2，我们可以估计为适应给定大小的名字空间，集群应当具有的节点数。
在Yahoo的集群上，DataNodes通常配备了4个0.75-1TB的磁盘，每个节点又大概会有2.5-3.5TB空间分配给HDFS，剩下的空间会被MapReduce中间结果，系统日志和OS使用。
如果我们假设平均节点容量为3TB，那么我们需要20,000个节点才能存下60PB的数据。为了与我们前面的10,0000节点目标相适应，每个节点必须配备8个磁盘。
结论3
为了容纳下100millon文件名字空间对应的数据，一个HDFS集群需要10,000个配备了8个磁盘的节点。这样的一个集群的总的存储容量是60PB。
需要注意的是，这些估算结果是基于1.5的blcok-per-file比率以及128MB的block大小的假设。如果该比率或者block大小增长了，那么1GB的RAM就能支持更多的物理存储，反之亦然。
不幸的是，根据实际的观察，blcok-per-file比率在文件系统的生命周期内有降低的趋势，这就意味着单个名字空间服务器的对象数(对应着内存占用量)比物理数据存储增长地要快。这就使得对象数问题(在λ=1时，就变成了文件数问题)成为集群可扩展性的实实在在的一个瓶颈。
Block Report,HearBeats
NameNode维护了一个已注册的DataNodes以及属于每个DataNode的blocks的列表。DataNode通过发送block report来向NameNode报告属于它的block副本。一个block report包括一个block ID，长度，及为每个block副本生成的世代戳(generation stamp)。
在DataNode注册完成之后就会立即发送block report。它会透露block的位置信息，而这些信息没有在NameNode的名字空间映像和修改日志中进行维护。之后，block reports会被周期性地发送，默认是一小时，同时作为一种完整性检查以保证NameNode具有关于集群block副本分布的最新信息。
在正常操作期间，DataNodes会向NameNode发送heartbeats以表明自己是活动的。默认的heartbeat区间是3秒。如果NameNode在10分钟内没有收到来自某个DataNode的heartbeat，它就会判定该DataNode已死亡，同时会将该DataNode的blocks调度到其他节点上。
Heartbeats也会携带一些关于磁盘总量、当前使用量以及在节点上当前正在进行的数据传输量的信息，这些信息在NameNode的空间和负载平衡决定中具有重要的作用。
HDFS集群中的通信是以一种避免NameNode直接调用DataNodes的方式进行组织的。它总是使用携带了一些重要指令的heartbeats来响应DataNodes。这些指令包括如下一些命令：
l 复制blocks到其他节点
l 删除本地的block副本
l 重新注册或者关闭节点
l 发送一个即时block report
这些命令对于维护整个系统的完整性是十分重要的，因此就算是在大规模的集群中，保持心跳的通畅也是非常重要的。NameNode每秒可以处理数千个心跳请求而不会影响到其他的NameNode操作。
内部负载
Block reports和heartbeats构成了集群的内部负载。该负载主要取决于集群中的DataNodes数量。如果内部负载过高，集群就可能会处于异常状态，而可能只能处理一些少数的几个外部客户端操作比如ls，read或者write。
本节会分析下NameNode需要将总处理能力中的多少用于内部负载。
假设集群是由每个具有6TB有效磁盘存储容量的10,000个DataNodes组成。这也是我们前面为满足目标需求，计算出的结果。如往常一样，我们的分析也是基于block-to-file比率为1.5的假设。该假设实际上也意味着，在DataNode的每两个blocks中就有一个是半空的。如果我们将一个全满的block和一个半空的block看做一对对待，那么每一对大概会占用200MB≈128MB+64MB的磁盘空间{!每个block平均大小就是100MB}。这就提供给我们一个估计结果，一个6TB的节点大概持有60,000个blocks。这就是DataNode发送给NameNode的block report的平均大小。
Block reports的发送是随机的，这样它们就不会同时到达NameNode。因此，NameNode接受到的block reports的平均个数是10,000/小时(10,000个nodes每一小时发送一次block reports)，每秒大概3个。
Heartbeats在当前的实现中并没有显式地进行随机化。理论上，可能会在同一时间到达NameNode，尽管可能性非常低。因此，我们假设NameNode必须能够处理10,000节点的集群上每秒产生的10,000个heartbeats。
为了测量NameNode性能，我实现了一个称为NNThroughputBenchmark的Benchmark程序，目前已是HDFS代码库的标准组成部分。
NNThroughputBenchmark是一个单机进程，它会启动NameNode应用程序，同时在同一个节点上运行大量的客户端线程。每个客户端线程会通过直接调用NameNode接口来执行同一个NameNode操作。该benchmark是用来测量NameNode每秒可执行的操作数。为避免由RPC连接和序列化引起的开销，该benchmark是运行在本地而不是远程的节点上。这样通过该测试就得到了纯NameNode性能上界。
下面的这些数字是通过在一个具有双核Xeon CPUs，32GB RAM和4个1TB磁盘的节点上运行NNThroughputBenchmark获取的。
表2表示了针对两个内部操作的NameNode吞吐率。需要注意的是block report吞吐率是以NameNode每秒处理的blocks数来度量的。
可以看到，NameNode每秒可以处理超过10{!639713/60000，每秒可以处理639713个blocks，每个节点的reports包含了该节点上的60000个blocks}个reports。而我们实际只需要每秒处理3个reports，因此我们可以知道，NameNode只需要不到总处理能力的30%就能够处理block reports。Heartbeat负载是3.3%{!10000/300000}，因此block reports和heartbeats的总内部负载仍然是小于30%的。
结论4
在一个具有60PB存储容量的10,000节点HDFS集群上的block reports和heartbeat产生的内部负载会消耗掉NameNode总体处理能力的30%。
因此，集群内部负载直接依赖于平均的block report大小和reports数目。Heartbeats的影响可以忽略。
也可以这样认为，内部负载与集群中的节点数和节点上的blocks平均数目成比例。因此，如果一个节点只有30,000个blocks，那么NameNode就只需要将15%的处理资源用于内部负载。因为节点虽然发送相同个数的block reports，但是每个block reports大小降低了一半。
反之，如果每个节点的平均blocks数目增长了，那么内部负载也会相应的增长。尤其是，这意味着block-to-file比率的降低(在相同文件系统大小下具有更多的小文件)会带来内部负载的上升，因此对于系统性能的影响是负面的。
Reasonable Load Expecations
从前面的章节看，好消息是NameNode可以将它70%的时间用来处理外部client请求。如果所有的clients以很高的频率向NameNode任意地发送请求，NameNode将很难去处理这些负载，可能会变得无法响应，有可能会让整个集群陷入泥潭而不能自拔。因为内部的负载请求并不比客户端请求具有更高的优先级。同时即使是在具有极端负载水平的小规模集群上，也有可能发生这种情况。
本节的目标是确定一个大规模集群(10,000节点，60PB数据)上合理的预期负载，同时估算下NameNode所能够处理的负载极限。
Hadoop集群通常用来运行MapReduce jobs。我们首先假设所有运行着不同tasks的100,000个客户端只对HDFS产生只读类型的负载。这是一个典型的job map执行阶段。
通常一个map task会产生map输出，它会被写入到本地磁盘。因为MapReduce服务器(task-trackers)与HDFS DataNodes共享集群节点，map输出会不可避免地与HDFS读取产生竞争。这会降低HDFS的读吞吐量，同时也会降低NameNode上的负载。因此，为了我们的分析目的，我们需要保证我们的tasks不会产生任何输出，否则NameNode上的负载会被降低。
典型地，一个map task一次会读取数据的一个block。在我们的场景中，一个文件由1.5个blocks组成。因此每个客户端平均读取96MB大小的Chunk(1.5*128MB/2)，所以我们假设每个客户端的一个读操作是96MB。
图1表明客户端的读操作由2个阶段组成：
1. 从NameNode处获取block位置信息
2. 将数据从最近的DataNode处拉过来
我们需要估算下客户端检索一个block副本的时间开销，基于此，我们就可以估计出NameNode预计会接受来自100,000个clients的多少个”get block location”请求。
DFSIO是一个针对HDFS的第一个标准benchmark。该benchmark是一个具有多个mappers和单个reducer的map-reduce job。每个mapper会向(从)不同的文件中写入(读取)数据。该job内的mapper要么是全读要么是全写，同时每个mapper传输相同的数据量。Mappers会收集IO统计信息并传送给reducer。Reducer会对它们求一个平均值及对该job的IO吞吐量进行汇总。这里关键的测量结果就是每个mapper的平均字节传输速率。
下面的结果来自于一个与NNThroughputBenchmark具有相同NameNode配置的4000节点集群，同时DataNodes与NameNode相比不同之处只在于它们只有8GB RAM。该集群由100个机柜组成，每个机柜有一个1 gigabit的内部交换机及一个4 gigabit的上行链路。
表3是由DFSIO benchmark提供的平均客户端读写吞吐率。
可以看到，一个客户端读取96MB数据将会花费1.45秒。根据我们的设想，客户端会为每个chunk数据或文件去NameNode获取block位置信息。因此100,000个客户端将会每秒对NameNode产生68750{!100000/1.45}个get-block-location请求。
根据NNThroughputBenchmark得到的另一系列吞吐率结果如下，它们代表了由NameNode每秒可以执行的打开(等同于get-block-location操作)及创建操作数目。
结果表明，在一个将30%能力用于内部负载的NameNode上可以处理超过88,000{!126119*(1-30%)}个get-block-location操作，这足以处理每秒68750个的读操作负载。
结论5
10000节点的HDFS集群在具有30%的内部负载的情况下，仍可以处理由100,000个HDFS客户端产生的只读负载。
写性能看起来就远没有这么乐观了。对于写操作，我们考虑一个类distcp的会产生大量写操作的工作负载。如前述，我们假设客户端每个写操作的平均大小是96MB。根据表3，每个客户端平均可以在2.4秒内写入96MB数据。这样100,000个客户端每秒就可以产生大概41,667{!100000/2.4}个create-block请求，但是根据表4，一个具有70%可用计算能力的NameNode每秒只能处理3920个create操作，这差距太大了。此外这还是未将那由DataNodes针对block副本创建成功向NameNode发送的125,000个确认信息(每个create-block操作会有三个)考虑在内。尽管这些确认信息不像create-block操作那样重量级，但是这仍是一个非常可观的额外负载。
即使NameNode将100%的处理能力用于外部tasks，客户端仍然不能全速进行它们的写操作。为等待NameNode的回复，将会导致严重的空等待。
结论6
由10,000节点集群上的100,000个HDFS客户端产生的合理的可预见负载将会超出单个NameNode的吞吐率容量。
分布式系统需要设计地具有线性的性能可扩展性：越多的工作节点应该能够产生与之成比例的工作量。上面的估算表明10,000个具有写密集型工作负载的HDFS客户端就能使NameNode达到饱和状态。在一个10000节点的集群上，平均下来每个节点才有一个客户端，但是当前的Hadoop集群实际上每个节点可以运行多达4个的客户端。这就使得单个的NameNode成为整个集群可扩展性的瓶颈。而此时增加writers的个数已经没有任何作用，客户端能够写入的量已经达到极限。
最终结论
可以看到一个具有单个名字空间节点的10,000节点集群可以很好地处理100,000个读者产生的负载，但是即使是10,000个写者也已经能够产生足以让NameNode饱和的工作负载，这使得它成为线性可扩展性的一个瓶颈。
这种在性能上的巨大差异，是因为获取block位置信息(由读取负载产生)是一个纯内存操作，而create操作(由写入负载产生)需要写入日志，这就受限于本地磁盘性能。
可以通过一些方式来改进NameNode性能，但是任何基于单个名字空间服务器的解决方案本质上都缺乏可扩展性。展望未来，如果再考虑上小文件的增长趋势，最彻底的解决方案应该是将用于进行负载平衡的名字空间服务器操作和内存空间占用进行分布式。有些分布式文件系统采用了这样的策略。
Ceph有一个名字空间服务器(MDS)集群，通过使用一个动态子树划分算法来将名字空间树均匀映射到MDs。论文[9]提供了一个具有128个MDS节点的430节点集群的实验结果。当MDS集群增长到128个节点时，每个MDS的吞吐率降低了50%。
Google最近也宣布GFS已经具有一个分布式的名字空间服务系统。新的GFS具有数百个名字空间服务器(masters)，每个包含100million的文件。每个文件被划分成了更小的block大小(现在是1MB，之前是64MB)。关于它的设计细节，可扩展性及性能目前还未公布。
Lustre在它的2.2版本中有一个集群化的名字空间实现。通过将目录切分到多个元数据服务器(MDS)，每个负载名字空间的一部分。文件通过一个针对文件名称的特定hash算法分配给特定的MDS。
致谢
感谢Jakob Homan和Rik Farrow对于本文的帮助。
参考文献
[1] P.H. Carns, W.B. Ligon III, R.B. Ross, and R. Thakur, “PVFS: A Parallel File System for Linux Clusters,” Proceedings of the 4th Annual Linux Showcase and Conference, 2000, pp. 317–327.
[2] S. Ghemawat, H. Gobioff, and S. Leung, “The Google File System,” Pro?ceedings of the ACM Symposium on Operating Systems Principles, Lake George, NY, October 2003, pp. 29–43.
[3] Lustre: http://www.lustre.org.
[4] M.K. McKusick and S. Quinlan, “GFS: Evolution on Fast-forward,” ACM Queue, vol. 7, no. 7, ACM, New York, NY. August 2009.
[5] O. O’Malley and A.C. Murthy, “Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds,” Yahoo! Developer Network Blog, May 11, 2009: http://developer.yahoo.net/blogs/hadoop/2009/05/hadoop_sorts_a_petabyte_in_162.html.
[6] F. Schmuck and R. Haskin, “GPFS: A Shared-Disk File System for Large Computing Clusters,” Proceedings of FAST ’02: 1st Conference on File and Stor?age Technologies (USENIX Association, 2002), pp. 231–244.
[7] K.V. Shvachko, “The Hadoop Distributed File System Requirements,” Ha?doop Wiki, June 2006: http://wiki.apache.org/hadoop/DFS_requirements.
[8] K.V. Shvachko and A.C. Murthy, “Scaling Hadoop to 4000 Nodes at Yahoo!,” Yahoo! Developer Network Blog, September 30, 2008: http://developer.yahoo.net/blogs/hadoop/2008/09/scaling_hadoop_to_4000_nodes_a.html.
[9] S. Weil, S. Brandt, E. Miller, D. Long, and C. Maltzahn, “Ceph: A Scal?able, High-Performance Distributed File System,” Proceedings of OSDI ’06: 7th Conference on Operating Systems Design and Implementation (USENIX Associa?tion, 2006).
[10] B. Welch, M. Unangst, Z. Abbasi, G. Gibson, B. Mueller, J. Small, J. Zelenka, and B. Zhou, “Scalable Performance of the Panasas Parallel File Sys?tem,” Proceedings of FAST ’08: 6th Conference on File and Storage Technologies (USENIX Association, 2008), pp. 17–33.
[11] “Compare Name-Node Performance When Journaling Is Performed into Local Hard-Drives or NFS,” July 30, 2008: http://issues.apache.org/jira/browse/HADOOP-3860.
[12] “Name-Node Memory Size Estimates and Optimization Proposal,” August 6, 2007: https://issues.apache.org/jira/browse/HADOOP-1687.