大话存储系列14——集群文件系统_大型存储中心。存储集群的构成

文件系统是操作系统的一个重要组成部分，通过对操作系统所管理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备的直接操作和资源管理。

根据计算环境和所提供功能的不同，文件系统可划分为四个层次，从低到高依次是：

单处理器单用户的本地文件系统，如DOS的文件系统；

多处理器单用户的本地文件系统，如OS/2的文件系统；

多处理器多用户的本地文件系统，如Unix的本地文件系统；

多处理器多用户的分布式文件系统，如Lustre文件系统.

平时大家有很多叫法：什么集群文件系统、san共享文件系统、分布式文件系统、并行文件系统。。等等等。。那么这些概念之间到底有什么联系呢？

 

 1、san共享式文件系统：其实这种叫法狭义上就是自助型、共享存储型的集群文件系统。广义上也可以泛指共享存储型的集群文件系统，可以是自助型，也可以是服务型。但是最常用的还是Stornext、中科蓝鲸BWFS和IBM SanFS这样的自助型共享存储集群。San共享文件系统又可被称为：“San文件系统”。

2、分布式文件系统：同一个文件系统下的文件（或者同一个文件的多个部分）不是被放在单一节点内，而是被分开存放在多个节点之内，这就是所谓的“分布式”的意义。分布式与共享式是对立的，所以分布式文件系统等价于非共享存储的集群文件系统。

3、并行文件系统：可以提供并行访问的集群文件系统。客户端访问这些被分开存储的文件时，可以直接从多个节点并行地读取多个文件，或者一个文件的多个部分，这就是并发的直接从存有对应数据的节点上来读取这些数据，这就是所谓的“并行”。

      相对于并行地串行，即串行文件系统，就是指客户端只能从所有节点中的一个节点来读写所有数据，如果需要读写的数据不在所连接的节点上，那么需要由这个节点来向存有对应数据的节点发起请求，将数据从对应节点通过内部交换矩阵传输过来之后，再传给客户端。也就是说数据是串行的传输的。分布不一定并行，但是并行一定是分布的。并行文件系统均要在主机客户端安装一个代理，或者一个新文件系统挂载器，用来专门实现并行访问。

4、集群文件系统：分布式文件系统、并行文件系统、共享式文件系统，三者统称为集群文件系统。 其中，“分布式”和“共享式”指的是集群中数据分布的方式，而“并行”指的是用户对这些数据的访问方式。分布和访问是两个层面，两种含义的。

集群文件系统其实最后演化成了两大阵营：一个是客户端直接发问后端的SAN的模式，另一个则是在客户端和后端FC SAN lun 之间引入基于以太网链路访问的IO节点模式。后者又可以根据客户端访问IO节点使用协议的不同而分为更多种类。

两大阵营各有利弊。直接访问后端SAN的模式，客户端与后端的磁盘阵列之间没有任何其他处理模块，所以其IO的效率是最高的，而且加上FC网络的速度，这个系统的速度和效率均较高。但是相对来讲，其成本也将随着客户端数量的增大而正比增加，因为目前FC适配器贵死了。。。此外由于后端的LUN皆是由MDC来挂载和管理，而系统中的MDC数量有限（目前最多两个），所以一旦两个MDC都出问题，那么整个系统就瘫痪了。

引入了IO节点之后，一方面客户端可以使用廉价的以太网来访问IO节点了，花费降低；另一方面，对于像Ibrix这种架构，所有节点都同时作为MDC和IO节点，IO节点就可以接管故障节点之前所挂载的lun以及文件系统，继续提供服务，只要系统中还剩一个IO节点/MDC，那么整个系统就不会瘫痪。容错高了，付出的代价就是IO传输效率的降低，毕竟以太网的速度比不上光纤。

1、分布式文件系统

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就象使用本地驱动器一样。

      本地文件系统（Local File System）是指文件系统管理的物理存储资源直接连接在本地节点上，处理器通过系统总线可以直接访问。

      分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。

由于互联网应用的不断发展，本地文件系统由于单个节点本身的局限性，已经很难满足海量数据存取的需要了，因而不得不借助分布式文件系统，把系统负载转移到多个节点上。

传统的分布式文件系统（如NFS）中，所有数据和元数据存放在一起，通过单一的存储服务器提供。这种模式一般称之为带内模式（In-band Mode）。随着客户端数目的增加，服务器就成了整个系统的瓶颈。因为系统所有的数据传输和元数据处理都要通过服务器，不仅单个服务器的处理能力有限，存储能力受到磁盘容量的限制，吞吐能力也受到磁盘I/O和网络I/O的限制。在当今对数据吞吐量要求越来越大的互联网应用中，传统的分布式文件系统已经很难满足应用的需要。

于是，一种新的分布式文件系统的结构出现了，那就是利用存储区域网络（SAN）技术，将应用服务器直接和存储设备相连接，大大提高数据的传输能力，减少数据传输的延时。在这样的结构里，所有的应用服务器都可以直接访问存储在SAN中的数据，而只有关于文件信息的元数据才经过元数据服务器处理提供，减少了数据传输的中间环节，提高了传输效率，减轻了元数据服务器的负载。

每个元数据服务器可以向更多的应用服务器提供文件系统元数据服务。这种模式一般称之为带外模式（Out-of-band Mode）。最近的Storage Tank、CXFS、Lustre、BWFS等都采用这样的结构，因此它们可以取得更好的性能和扩展性。区分带内模式和带外模式的主要依据是，关于文件系统元数据操作的控制信息是否和文件数据一起都通过服务器转发传送。前者需要服务器转发，后者是直接访问。

2、分布式文件系统访问方法

在大多数环境中，共享资源驻留在多台服务器上的各个共享文件夹中。要访问资源，用户或程序必须将驱动器映射到共享资源的服务器，或指定共享资源的通用命名约定 (UNC) 路径。例如:

　　\\服务器名\共享名

　　或

　　\\服务器名\共享名\路径\文件名

　　通过 DFS(分布式文件系统)，一台服务器上的某个共享点能够作为驻留在其他服务器上的共享资源的宿主。DFS 以透明方式链接文件服务器和共享文件夹，然后将其映射到单个层次结构，以便可以从一个位置对其进行访问，而实际上数据却分布在不同的位置。用户不必再转至网络上的多个位置以查找所需的信息，而只需连接到:

　　\\DfsServer\Dfsroot

　　用户在访问此共享中的文件夹时将被重定向到包含共享资源的网络位置。这样，用户只需知道 DFS 根目录共享即可访问整个企业的共享资源。

　　DFS 拓扑从 DFS 树的根目录开始。位于逻辑层次结构顶部的 DFS 根目录映射到一个物理共享。DFS 链接将域名系统 (DNS) 名称映射到目标共享文件夹或目标 DFS 根目录的 UNC 名称。

当 DFS 客户端访问 DFS 共享文件夹时，DFS 服务器将 DNS 名称映射到 UNC 名称并将引用返回给该客户端，以使它能够找到共享文件夹。将 DNS 名称映射到 UNC 名称使数据的物理位置对用户是透明的，这样用户便无须记住存储文件夹的服务器。

当 DFS 客户端请求 DFS 共享的引用时，DFS 服务器将使用分区情况表 (PKT) 将 DFS 客户端定向到物理共享。对于基于域的 DFS，PKT 存储在 Active Directory 中;对于独立的 DFS，PKT 存储在注册表中。在网络环境中，PKT 维护有关 DFS 拓扑的所有信息，包括其到基础物理共享的映射。DFS 服务器将 DFS 客户端定向到与请求的 DFS 链接相对应的副本共享列表后，DFS 客户端使用 Active Directory 站点拓扑连接到同一站点中的一个副本，如果该站点中没有提供副本，则连接到该站点以外的一个副本。

3、HDFS文件系统架构

Hadoop 分布式文件系统 (HDFS) 是运行在通用硬件上的分布式文件系统。HDFS 提供了一个高度容错性和高吞吐量的海量数据存储解决方案。HDFS 已经在各种大型在线服务和大型存储系统中得到广泛应用，已经成为各大网站等在线服务公司的海量存储事实标准，多年来为网站客户提供了可靠高效的服务。

随着信息系统的快速发展，海量的信息需要可靠存储的同时，还能被大量的使用者快速地访问。传统的存储方案已经从构架上越来越难以适应近几年来的信息系统业务的飞速发展，成为了业务发展的瓶颈和障碍。

HDFS 通过一个高效的分布式算法，将数据的访问和存储分布在大量服务器之中，在可靠地多备份存储的同时还能将访问分布在集群中的各个服务器之上，是传统存储构架的一个颠覆性的发展。HDFS 可以提供以下特性：

• 可自我修复的分布式文件存储系统
• 高可扩展性，无需停机动态扩容
• 高可靠性，数据自动检测和复制
• 高吞吐量访问，消除访问瓶颈
• 使用低成本存储和服务器构建

分布式文件系统 HDFS 特性
高吞吐量访问
HDFS 的每个数据块分布在不同机架的一组服务器之上，在用户访问时，HDFS 将会计算使用网络最近的和访问量最小的服务器给用户提供访问。由于数据块的每个复制拷贝都能提供给用户访问，而不是从单数据源读取，HDFS 对于单数据块的访问将是传统存储方案的数倍。
对于一个较大的文件，HDFS 将文件的不同部分存放于不同服务器之上。在访问大型文件时，系统可以并行从服务器阵列中的多个服务器并行读入，增加了大文件读入的访问带宽。
通过以上实现，HDFS 通过分布式计算的算法，将数据访问均摊到服务器阵列中的每个服务器的多个数据拷贝之上，单个硬盘或服务器的吞吐量限制都可以数倍甚至数百倍的突破，提供了极高的数据吞吐量。

无缝容量扩充
HDFS 将文件的数据块分配信息存放在NameNode 服务器之上，文件数据块的信息分布地存放在 DataNode 服务器上。当整个系统容量需要扩充时，只需要增加DataNode 的数量，系统会自动地实时将新的服务器匹配进整体阵列之中。之后，文件的分布算法会将数据块搬迁到新的DataNode 之中，不需任何系统宕机维护或人工干预。通过以上实现，HDFS 可以做到在不停止服务的情况下实时地加入新的服务器作为分布式文件系统的容量升级，不需要人工干预文件的重新分布。
高度容错
HDFS 文件系统假设系统故障(服务器、网络、存储故障等)是常态，而不是异常。因此通过多方面保证数据的可靠性。数据在写入时被复制多份，并且可以通过用户自定义的复制策略分布到物理位置不同的服务器上;数据在读写时将自动进行数据的校验，一旦发现数据校验错误将重新进行复制;HDFS 系统在后台自动连续的检测数据的一致性，并维持数据的副本数量在指定的复制水平上。

1 、硬件错误是常态，而非异常情况， HDFS 可能是有成百上千的 server 组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是 HDFS 的核心架构目标。
2 、跑在 HDFS 上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3 、 HDFS 以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至 T 字节，一个单一 HDFS 实例应该能支撑数以千万计的文件。
4 、 HDFS 应用对文件要求的是 write-one-read-many 访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如 MapReduce 框架，或者一个 web crawler 应用都很适合这个模型。
5 、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好， HDFS 提供给应用这样的接口。
6 、在异构的软硬件平台间的可移植性。

Namenode和Datanode
HDFS 采用 master/slave 架构。一个 HDFS 集群是有一个 Namenode 和一定数目的 Datanode 组成。 Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode 在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个 block ，这些 block 存储在 Datanode 集合里。 Namenode 执行文件系统的 namespace 操作，例如打开、关闭、重命名文件和目录，同时决定 block 到具体 Datanode 节点的映射。 Datanode 在 Namenode 的指挥下进行 block 的创建、删除和复制。 Namenode 和 Datanode 都是设计成可以跑在普通的廉价的运行 linux 的机器上。 HDFS 采用 java 语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的 Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。

单一节点的 Namenode 大大简化了系统的架构。 Namenode 负责保管和管理所有的 HDFS 元数据，因而用户数据就不需要通过 Namenode （也就是说文件数据的读写是直接在 Datanode 上）。

文件系统的namespace
HDFS 支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。 HDFS 不支持 user quotas 和访问权限，也不支持链接（ link) ，不过当前的架构并不排除实现这些特性。 Namenode 维护文件系统的 namespace ，任何对文件系统 namespace 和文件属性的修改都将被 Namenode 记录下来。应用可以设置 HDFS 保存的文件的副本数目，文件副本的数目称为文件的 replication 因子，这个信息也是由 Namenode 保存。

数据复制
HDFS 被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成 block 序列，除了最后一个 block ，所有的 block 都是同样的大小。文件的所有 block 为了容错都会被复制。每个文件的 block 大小和 replication 因子都是可配置的。 Replication 因子可以在文件创建的时候配置，以后也可以改变。 HDFS 中的文件是 write-one ，并且严格要求在任何时候只有一个 writer 。 Namenode 全权管理 block 的复制，它周期性地从集群中的每个 Datanode 接收心跳包和一个 Blockreport 。心跳包的接收表示该 Datanode 节点正常工作，而 Blockreport 包括了该 Datanode 上所有的 block 组成的列表。

1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽大。
通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到多个机架。
在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。

2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。

3、SafeMode
Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列表。每个block都有指定的最小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些block复制到其他Datanode。

文件系统元数据的持久化
Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件系统上。
Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G内存的Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用（apply)在内存中的FsImage，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。

六、通讯协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和Datanode的RPC请求。

七、健壮性
HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错误，或者文件的replication因子增大。

2、集群均衡
HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前还没有实现。

3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了HDFS文件内容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些校验和在同一个HDFS namespace下。当客户端检索文件内容，它会确认从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该block的副本。

4、元数据磁盘错误
FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的时候，它总是选取最近的一致的FsImage和Editlog使用。
Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。

5、快照
快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。

八、数据组织
1、数据块
兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数据块给客户端。客户端将本地临时文件flush到指定的Datanode上。当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的Datanode，然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到持久存储。如果Namenode在文件关闭前挂了，该文件将丢失。
上述方法是对通过对HDFS上运行的目标应用认真考虑的结果。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。

3、流水线复制
当某个客户端向HDFS文件写数据的时候，一开始是写入本地临时文件，假设该文件的replication因子设置为3，那么客户端会从Namenode获取一张Datanode列表来存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分（4kb)地接收数据，将每个部分写入本地仓库，并且同时传输该部分到第二个Datanode节点。第二个Datanode也是这样，边收边传，一小部分一小部分地收，存储在本地仓库，同时传给第三个Datanode，第三个Datanode就仅仅是接收并存储了。这就是流水线式的复制。

九、可访问性
HDFS给应用提供了多种访问方式，可以通过DFSShell通过命令行与HDFS数据进行交互，可以通过java API调用，也可以通过C语言的封装API访问，并且提供了浏览器访问的方式。正在开发通过WebDav协议访问的方式。具体使用参考文档。
十、空间的回收
1、文件的删除和恢复
用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲空间的增加之间会有一个等待时间延迟。
当被删除的文件还保留在/trash目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash目录并检索该文件。/trash目录仅仅保存被删除文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。

2、Replication因子的减小
当某个文件的replication因子减小，Namenode会选择要删除的过剩的副本。下次心跳检测就将该信息传递给Datanode，Datanode就会移除相应的block并释放空间，同样，在调用setReplication方法和集群中的空闲空间增加之间会有一个时间延迟。

精彩连接：

http://blog.csdn.net/liuben/article/details/6284551