文件系统简介：
理论上说一个嵌入式设备如果内核能够运行起来，且不需要运行用户进程的话，是不需要文件系统的。文件系统简单的说就是一种目录结构，由于linux操作系统的设备在系统中
是以文件的形式存在，将这些文件进行分类管理以及提供和内核交互的接口，就形成一定的目录结构也就是文件系统。文件系统是为用户反映系统的一种形式，为用户提供一个检测控制系统的接口。
根文件系统，就是一种特殊的文件系统。那么根文件系统和普通的文件系统有什么区别呢？由于根文件系统是内核启动时挂在的第一个文件系统，那么根文件系统就要包括Linux 启动时所必须的目录和关键性的文件，例如Linux启动时都需要有用户进程init对应的文件，在Linux挂载分区时Linux一定会找/etc/fstab这个挂载文件等，根文件系统中还包括了许多的应用程序，如/bin目录下的命令等。任何包括这些Linux 系统启动所必须的文件的文件系统都可以称为根文件系统。
Linux支持多种文件系统，包括ext2、ext3、vfat、ntfs、iso9660、jffs、ramfs和nfs 等，为了对各类文件系统进行统一管理，Linux引入了虚拟文件系统VFS，为各类文件系统提供一个统一的操作界面和应用编程接口。下图是linux文件系统层次关系图。
MTD
MTD(memory technology device内存技术设备)是用于访问memory设备（ROM、flash）的Linux的子系统。MTD的主要目的是为了使新的memory设备的驱动更加简单，为此它在硬件和上层之间提供了一个抽象的接口。MTD的所有源代码在/drivers/mtd子目录下。
nfs简介
网络文件系统，英文Network File System(NFS)。是由SUN公司研制的UNIX表示层协议(pressentation layer protocol)，能使使用者访问网络上别处的文件就像在使用自己的计算机一样。
initramfs简介
当Linux 内核启动系统时，它必须找到并执行第一个用户程序，通常是init。用户程序存在于文件系统，故Linux 内核必须找到并挂载上第一个(根)文件系统，方能成功开机。通常，可用的文件系统都列在/etc/fstab，所以mount 可以找到它们。但/etc/fstab 它本身就是一个文件，存在于文件系统中。找到第一个文件系统成为鸡生蛋蛋生鸡的问题，而为了解决它，内核开发者建立内核命令列选项root=，用来指定root 文件系统存在于哪个设备上。
如果在过去，root= 很容易解释。它可以是软盘或硬盘上的分区。如今root 文件系统可以存在于各种不同类型的硬件(SCSI, SATA, flash MTD) ，或是由不同类型硬件所建立的RAID 上。它的位臵随着不同的启动方式而不同，像可热插拔的USB 设备被插到有多个USB 孔的系统上- 当有多个USB 设备时，哪一个是正确的？root 文件系统也可能被压缩(如何解压？)，被加密(用什么keys？)，或loopback 挂载(哪里？)。它甚至可以存在外部的网络服务器上，需要内核去取得DHCP 地址，完成DNS lookup，并登入到远程服务器(需账号及密码)。这些操作必须都在内核可以找到并执行第一个userspace 程序之前完成。
如今，root= 已没有足够的信息。即使将所有特殊案例的行为都放进内核也无法帮助设备列举，加密，或网络登入这些随着系统不同而不同的系统。更糟的是，替核心加入这些复杂的工作，就像是用汇编语言写web 软件：可以做到，但使用适当的工具会更容易完成。
为了这个不断增加复杂度的工作，核心开发者决定去寻求更好的方法来解决这整个问题。Linux 2.6 核心将一个小的ram-based initial root filesystem(initramfs) 包含进内核，且若这个文件系统包含一个程序init，核心会将它当作第一个程序执行。此时，找寻其它文件系统并执行其它程序已不再是内核的问题，而是新程序的工作。initramfs 的内容不需是一般功能。若给定系统的root 文件系统存在于一个加密过的网络块设备，且网络地址、登入、加密都存在USB 设备"larry" (需密码方能存取)里，系统的initramfs 可以有特殊功能的程序，它知道这些事，并使这可以运作。
大部分系统将initramfs作为挂载最终根文件系统的临时文件系统，但也有些系统由于缺少存储介质，而直接使用initramfs的。
jffs2文件系统
JFFS2是JFFS的后继者，由Red Hat重新改写而成。JFFS2的全名为Journalling Flash File System Version 2（闪存日志型文件系统第2版），其功能就是管理在MTD设备上实现的日志型文件系统。与其他的存储设备存储方案相比，JFFS2并不准备提供让传统文件系统也可以使用此类设备的转换层。它只会直接在MTD设备上实现日志结构的文件系统。JFFS2会在安装的时候，扫描MTD设备的日志内容，并在RAM中重新建立文件系统结构
本身。
除了提供具有断电可靠性的日志结构文件系统，JFFS2还会在它管理的MTD设备上实现“损耗平衡”和“数据压缩”等特性。
yaffs文件系统
YAFFS(Yet Another Flash File System)文件系统是专门为NandFlash设计的文件系统，与JFFS/JFFS2文件系统有些类似，不同之处是JFFS/JFFS2文件系统最初是为NorFlash 的应用场合设计的，而NorFlash和NandFlash本质上有较大的区别（坏块、备用区、容量），
所以尽管JFFS/JFFS2文件系统也能应用于NandFlash，但对于NanFlash来说通常不是最优方案（性能较低和启动速度稍慢）。而YAFFS利用NandFlash提供的每个页面16字节或64字节的Spare区（OOB备用区）空间来存放ECC和文件系统的组织信息，能够实现错误检测和坏块处理。这样的设计充分考虑了NandFlash以页面为存取单元的特点，将文件组织成固定大小的数据段，能够提高文件系统的加载速度。
YAFFS目前有YAFFS、YAFFS2两个版本，一般来说，YAFFS对小页面（512B+16B/页）有很好的支持，YAFFS2对更大的页面（2K+64B/页）支持更好。
ubifs文件系统
由IBM、nokia工程师Thomas Gleixner，Artem Bityutskiy等人于2006年发起，致力于开发性能卓越、扩展性高的FLASH专用文件系统，以解决当前嵌入式环境下以FLASH 作为MTD设备使用时的技术瓶颈。
开发背景：
FLASH特性：
FLASH是一类电可擦出可编程存储体，在使用方式上与硬磁盘最大不同是：
FLASH文件系统所必须的关键技术：
1. 由于FLASH的“先擦除后写”的特性决定，必须（或者说所被公认为）采用异地更新
策略（out-of-place update)。
2. 采用异地更新策略就必须（或者说所被公认为）采用日志文件系统来管理。
3. 采用日志文件系统就必须（或者说所被公认为）实现垃圾回收（garbage collection)
4. 由于FLASH的物理擦除块（Physical Erase Block）只有有限次有效擦除，所以必
须（或者说所被公认为）采用“负载平衡”（我比较喜欢翻译为“损益均衡”——一个经济学术语）(Wear- Leveling)技术，即保证上的（几乎）所有PEB的擦除次数趋向于均衡化，从而避免小部分PEB大大先于其他PEB而”坏“掉。
当前嵌入式FLASH解决方案多采用：
1. 无文件系统直接使用FLASH：缺点很明显
2. 采用传统文件系统，如ext2,ext3, FAT16/32, dos，Cramfs 等：这些文件系统本来
是为传统的磁盘体开发的，他们无法高效的管理以FLASH作为介质的文件系统，特别是在FLASH的使用寿命上。于是出现了第3中方案。
3. 采用FTL／NFTL（flash 转换层／nand flash转换层）＋传统文件系统：FTL的使
用就是针对FLASH的特有属性，通过硬件的方式来实现日志管理、损益均衡等技术。
但实践证明，由于各方面因素导致本方案有一定的局限性。
4. FLASH专用文件系统，如JFFS1／2，YAFFS等，他们从一定程度上缓解了flash 使用上的技术瓶颈。但也仍然存在诸多问题：如内存消耗大，对FLASH容量、文件系统大小、内容、访问模式等的线性依赖，损益均衡能力差活过渡损益。随作FLASH容量逐渐暴涨，JFFS，YAFFS几乎无法管理如此大的FLASH。
UBI：一种类似于LVM的逻辑卷管理层。主要实现损益均衡，逻辑擦除块、卷管理，坏块管理等。
UBIFS：基于UBI的FLASH日志文件系统。
６苏州大学学报（工科版）第３０卷 图１Ｉ－ＩＤＦＳ架构 ２ＨＤＦＳ与ＬｉｎｕｘＦＳ比较 ＨＤＦＳ的节点不管是ＤａｔａＮｏｄｅ还是ＮａｍｅＮｏｄｅ都运行在Ｌｉｎｕｘ上，ＨＤＦＳ的每次读／写操作都要通过ＬｉｎｕｘＦＳ的读／写操作来完成，从这个角度来看，ＬｉｎｕｘＰＳ是ＨＤＦＳ的底层文件系统。 ２．１目录树（ＤｉｒｅｃｔｏｒｙＴｒｅｅ） 两种文件系统都选择“树”来组织文件，我们称之为目录树。文件存储在“树叶”，其余的节点都是目录。但两者细节结构存在区别，如图２与图３所示。 一二 Ｒｏｏｔ ＼ 图２ＩｔＤＦＳ目录树围３ＬｉｎｕｘＦＳ目录树 ２．２数据块（Ｂｌｏｃｋ） Ｂｌｏｃｋ是ＬｉｎｕｘＦＳ读／写操作的最小单元，大小相等。典型的ＬｉｎｕｘＦＳＢｌｏｃｋ大小为４ＭＢ，Ｂｌｏｃｋ与ＤａｔａＮ－ｏｄｅ之间的对应关系是固定的、天然存在的，不需要系统定义。 ＨＤＦＳ读／写操作的最小单元也称为Ｂｌｏｃｋ，大小可以由用户定义，默认值是６４ＭＢ。Ｂｌｏｃｋ与ＤａｔａＮｏｄｅ的对应关系是动态的，需要系统进行描述、管理。整个集群来看，每个Ｂｌｏｃｋ存在至少三个内容一样的备份，且一定存放在不同的计算机上。 ２．３索引节点（ＩＮｏｄｅ） ＬｉｎｕｘＦＳ中的每个文件及目录都由一个ＩＮｏｄｅ代表，ＩＮｏｄｅ中定义一组外存上的Ｂｌｏｃｋ。 ＨＤＰＳ中ＩＮｏｄｅ是目录树的单元，ＨＤＦＳ的目录树正是在ＩＮｏｄｅ的集合之上生成的。ＩＮｏｄｅ分为两类，一类ＩＮｏｄｅ代表文件，指向一组Ｂｌｏｃｋ，没有子ＩＮｏｄｅ，是目录树的叶节点；另一类ＩＮｏｄｅ代表目录，没有Ｂｌｏｃｋ，指向一组子ＩＮｏｄｅ，作为索引节点。在Ｈａｄｏｏｐ０．１６．０之前，只有一类ＩＮｏｄｅ，每个ＩＮｏｄｅ都指向Ｂｌｏｃｋ和子ＩＮ－ｏｄｅ，比现有的ＩＮｏｄｅ占用更多的内存空间。 ２．４目录项（Ｄｅｎｔｒｙ） Ｄｅｎｔｒｙ是ＬｉｎｕｘＦＳ的核心数据结构，通过指向父Ｄｅｎ姆和子Ｄｅｎｔｒｙ生成目录树，同时也记录了文件名并 指向ＩＮｏｄｅ，事实上是建立了＜ＦｉｌｅＮａｍｅ，ＩＮｏｄｅ＞，目录树中同一个ＩＮｏｄｅ可以有多个这样的映射，这正是连
Hadoop分布式文件系统：架构和设计 引言 (2) 一前提和设计目标 (2) 1 hadoop和云计算的关系 (2) 2 流式数据访问 (2) 3 大规模数据集 (2) 4 简单的一致性模型 (3) 5 异构软硬件平台间的可移植性 (3) 6 硬件错误 (3) 二HDFS重要名词解释 (3) 1 Namenode (4) 2 secondary Namenode (5) 3 Datanode (6) 4 jobTracker (6) 5 TaskTracker (6) 三HDFS数据存储 (7) 1 HDFS数据存储特点 (7) 2 心跳机制 (7) 3 副本存放 (7) 4 副本选择 (7) 5 安全模式 (8) 四HDFS数据健壮性 (8) 1 磁盘数据错误，心跳检测和重新复制 (8) 2 集群均衡 (8) 3 数据完整性 (8) 4 元数据磁盘错误 (8) 5 快照 (9)
引言 云计算（cloud computing)，由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。在此过程中被服务者只是提供需求并获取服务结果，对于需求被服务的过程并不知情。同时服务者以最优利用的方式动态地把资源分配给众多的服务请求者，以求达到最大效益。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS 能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 一前提和设计目标 1 hadoop和云计算的关系 云计算由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。针对海量文本数据处理,为实现快速文本处理响应,缩短海量数据为辅助决策提供服务的时间,基于Hadoop云计算平台,建立HDFS分布式文件系统存储海量文本数据集,通过文本词频利用MapReduce原理建立分布式索引,以分布式数据库HBase 存储关键词索引,并提供实时检索,实现对海量文本数据的分布式并行处理.实验结果表 明,Hadoop框架为大规模数据的分布式并行处理提供了很好的解决方案。 2 流式数据访问 运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3 大规模数据集 运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
几种Nand flas文件系统的对比 1.来源：NLE-FFS: A Flash File System with PRAM for Non-linear Editing For thesedevices, NAND flash memory has became the most attractive storage medium due to outstanding characteristics such as its increased capacity, low power consumption, small size and light weight. For the efficient management of NAND flashmemory, several flash file systems have been proposed, including JFFS2, YAFFS2, CFFS and PFFS. several file systems such as MNFS,NAMU and ScaleFFS have been designed for real-time recording /playback and large-capacity storage. A. YAFFS2 YAFFS2 is the most widely employed file system for NAND flash memory. YAFFS2 essentially saves the object ID (file ID) and the chunk (page) number in the spare region to show the offset of a page and the owner file of the page. Therefore, YAFFS2 reads the spare regions and object headers to establish the metadata in memory. Although YAFFS2 is designed to support NAND flash memory, it has scalability problems. With YAFFS2, the location of the updated page is saved in NAND flash pages or spare regions, as shown in Fig. 10 (a); hence, the file system
分布式存储系统的一些理解和实践 张建伟 一、分布式存储系统介绍 1.简介 互联网数据规模越来越大，并发请求越来越高，传统的关系数据库，在很多使用场景下并不能很好的满足需求。分布式存储系统应运而生。它有良好的扩展性，弱化关系数据模型，甚至弱化一致性要求，以得到高并发和高性能。按功能分类，主要有以下几种： ?分布式文件系统 hdfs ceph glusterfs tfs ?分布式对象存储 s3(dynamo) ceph bcs(mola) ?分布式表格存储 hbase cassandra oceanbase ?块存储 ceph ebs(amazon) 分布式存储系统，包括分布式系统和单机存储两部分；不同的系统，虽在功能支持、实现机制、实现语言等方面是有差异的，但其设计时，关注的关键问题是基本相同的。单机存储的主流实现方式，有hash引擎、B+树引擎和LSM树(Log Structured Merge Tree)三种，不展开介绍。本文第二章节，主要结合hbase、cassandra和ceph，讲下分布式系统设计部分，需要关注的关键问题。 2.适用场景 各分布式存储系统功能定位不尽相同，但其适用和不适用的场景，在一定程度上是相同的，如下。
1)适用 大数据量（大于100T，乃至几十PB） key/value或者半结构化数据 高吞吐 高性能 高扩展 2)不适用 Sql查询 复杂查询，如联表查询 复杂事务 二、分布式存储系统设计要点 1.数据分布 分布式存储，可以由成千甚至上万台机器组成，以实现海量数据存储和高并发。那它最先要解决的就是数据分布问题，即哪些数据存储在哪些机器（节点）上。常用的有hash类算法和用meta表映射两种方式。一般完全分布式的设计（无master节点），会用hash类算法；而集中式的设计（有master节点）用meta表映射的方式。两者各有优缺点，后面讲到具体问题时再做比较。 1)一致性hash 将存储节点和操作的key（key唯一标识存储的object，有时也叫object name）都hash到0~2的32次方区间。映射到如下环中的某个位置。沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。如下图所示：
1DFS系统 (DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布 分布式文件系统 式计算环境(DCE)中的文件系统部分。 如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式： 只读共享任何客户机只能访问文件，而不能修改它，这实现起来很简单。 受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。 并发写操作这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。 NFS和AFS的区别 NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步： 无状态系统在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS 就是个无状态系统。 回呼(Callback)系统在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。 无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若
HDFS分布式文件系统具备的优点 随着互联网数据规模的不断增大，对文件存储系统提出了更高的要求，需要更大的容量、更好的性能以及更高安全性的文件存储系统，与传统分布式文件系统一样，HDFS分布式文件系统也是通过计算机网络与节点相连，但也有优于传统分布式文件系统的优点。 1. 支持超大文件 HDFS分布式文件系统具有很大的数据集，可以存储TB或PB级别的超大数据文件，能够提供比较高的数据传输带宽与数据访问吞吐量，相应的，HDFS开放了一些POSIX的必须接口，容许流式访问文件系统的数据。 2. 高容错性能 HDFS面向的是成百上千的服务器集群，每台服务器上存储着文件系统的部分数据，在集群的环境中，硬件故障是常见的问题，这就意味着总是有一部分硬件因各种原因而无法工作，因此，错误检测和快速、自动的恢复是HDFS最核心的架构目标，因此，HDFS具有高度的容错性。 3. 高数据吞吐量 HDFS采用的是“一次性写，多次读”这种简单的数据一致性模型，在HDFS 中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了，这样简单的一致性模型，有利于提高吞吐量。 4. 流式数据访问 HDFS的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理，应用程序能以流的形式访问数据
集。 Hadoop已经迅速成长为首选的、适用于非结构化数据的大数据分析解决方案，HDFS分布式文件系统是Hadoop的核心组件之一，保证了大数据的可靠存储，与MapReduce配合使用，可以对结构化和复杂大数据进行快速、可靠分析，从而为企业做出更好的决策，促进收入增长，改善服务，降低成本提供有力支撑！
文件系统简介： 理论上说一个嵌入式设备如果内核能够运行起来，且不需要运行用户进程的话，是不需要文件系统的。文件系统简单的说就是一种目录结构，由于linux操作系统的设备在系统中 是以文件的形式存在，将这些文件进行分类管理以及提供和内核交互的接口，就形成一定的目录结构也就是文件系统。文件系统是为用户反映系统的一种形式，为用户提供一个检测控制系统的接口。 根文件系统，就是一种特殊的文件系统。那么根文件系统和普通的文件系统有什么区别呢？由于根文件系统是内核启动时挂在的第一个文件系统，那么根文件系统就要包括Linux 启动时所必须的目录和关键性的文件，例如Linux启动时都需要有用户进程init对应的文件，在Linux挂载分区时Linux一定会找/etc/fstab这个挂载文件等，根文件系统中还包括了许多的应用程序，如/bin目录下的命令等。任何包括这些Linux 系统启动所必须的文件的文件系统都可以称为根文件系统。 Linux支持多种文件系统，包括ext2、ext3、vfat、ntfs、iso9660、jffs、ramfs和nfs 等，为了对各类文件系统进行统一管理，Linux引入了虚拟文件系统VFS，为各类文件系统提供一个统一的操作界面和应用编程接口。下图是linux文件系统层次关系图。 MTD MTD(memory technology device内存技术设备)是用于访问memory设备（ROM、flash）的Linux的子系统。MTD的主要目的是为了使新的memory设备的驱动更加简单，为此它在硬件和上层之间提供了一个抽象的接口。MTD的所有源代码在/drivers/mtd子目录下。
分布式文件系统架构设计 1. 前言...................................................... 3.
2. HDFS1 (3) 3. HDFS2 (5) 4. HDFS3 ............................................................................................. 1 1 5. 结语..................................................... 1.5
1. 刖言 Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System )，简称HDFS，解 决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce ，解决了海量数据如何计 算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。而我 们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。 Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。同时也相对应的有HDFS1 ，HDFS2，HDFS3三个大版本。后面的HDFS的版本，都是对前一个版本的架构进行了调整优 化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我 们的系统架构能力。 2. HDFS1
DFS使用方法总结（超详细） 使用分布式文件系统 (DFS)，系统管理员可以使用户方便地访问和管理物理上分布在网络各处的文件。通过DFS，可以使分布在多个服务器上的文件如同位于网络上的一个位置一样显示在用户面前。 您可采用两种方式实施分布式文件系统：一种是独立的根目录分布式文件系统，另一种是域分布式文件系统。 独立的DFS根目录： 不使用 Active Directory。 至多只能有一个根目录级别的目标。 使用文件复制服务不能支持自动文件复制。 通过服务器群集支持容错。 域DFS根目录： 必须宿主在域成员服务器上。 使它的DFS名称空间自动发布到 Active Directory 中。 可以有多个根目录级别的目标。 通过 FRS 支持自动文件复制。 通过 FRS 支持容错。 分布式文件系统 (DFS) 映射由一个DFS根目录、一个或多个DFS链接以及指向一个或多个目标的引用组成。 DFS根目录所驻留的域服务器称为主服务器。通过在域中的其他服务器上创建根目标，可以复制DFS根目录。这将确保在主服务器不可用时，文件仍可使用。因为域分布式文件系统的主服务器是域中的成员服务器，所以默认情况下，DFS映射将自动发布到 Active Directory 中，从而提供了跨越主服务器的DFS拓扑同步。这反过来又对DFS根目录提供了容错性，并支持目标的可选复制。通过向DFS根目录中添加DFS链接，您可扩展DFS映射。Windows Server 2003 家族对DFS映射中分层结构的层数的唯一限制是对任何文件路径最多使用 260 个字符。新DFS链接可以引用具有或没有子文件夹的目标，或引用整个Windows Server 2003 家族卷。 创建DFS根目录 使用DFS管理工具，您可以指定某个目标，指派它为DFS根目录。除了访问该目标外，用户还可以访问该目标的任何子文件夹。使用 Windows Server 2003 Enterprise Edition 或Windows Server 2003 Datacenter Edition 时，您可在单独计算机上作为多个DFS根目录的宿主。由于DFS Active Directory 对象的大小，大型的基于域的DFS名称空间可能会显著地增加网络传输量。因此，建议您为域根使用的DFS链接的个数少于 5000。建议在运行 Windows Server 2003 的服务器上的独立的根目录的最大名称空间为 50,000 个链接。 如何创建DFS根目录: 1.打开分布式文件系统。 2.在“操作”菜单上，单击“新建根目录”。
JFFS文件系统和YAFFS文件系统的比较 NAND flash文件系统JFFS2和YAFFS比较JFFS是由瑞典的Axis Communications Ab公司开发的(1999,以GNU发布),针对flash设备的特性为嵌入式设备开发的.(我边上的兄弟曾想去那里作毕业设计) JFFS1和JFFS2的设计中都考虑到了FLASH的特性特别是满足了上述3个条件,包括了垃圾回收,坏块管理等功能. 这两种文件系统属于LFS(Log-structured File System).这种文件系统的特点是一旦数据出错,容易恢复,但是系统运行是需要占用一定的内存空间,这些空间就是用来存储”log”的. JFFS的缺点就是加载时间太长,因为每次加载都需要将FLASH上的所有节点(JFFS的存储单位)到内存,这样也占用了可观的内存空间.除此之外,”circle log”设计使得在对文件数据进行所有的数据都会被重写,这样造成不必要的时间,同时也会减少FLASH的寿命. JFFS2对JFFS1作了些改进,比如所需的内存变少了,垃圾回收机制也优化了. 针对JFFS1,JFFS2的缺点,JFFS3出现了. YAFFS1 ">“Yet Another Flash File System”作者是新西兰的Charles Manning为一家名叫Alpha one 的公司(https://www.doczj.com/doc/0315180171.html,/)设计的,是第一个为NAND Flash设计的文件系统.共两个版本YAFFS1 和YAFFS2. YAFFS1支持512Bytes/Page的NAND Flash;后者YAFFS2支持2kBytes/Page的NAND Flash. YAFFS文件系统也属于LFS. 跟其他文件系统比较,它具有更好的可移植性,甚至可以使用在没有操作系统的设备上(called “YAFFS/Direct”). YAFFS采用模块化设计,虽然最初是用在linux系统上的,但是也已经移植到其他系统比如wince. 还有个突出的优点是它在mount的时候需要很少的内存.(如果是小页—512byte/page,每1MByte NAND大约需要4KBytes内存;大页需要大概1KBytes RAM/1MByte NAND) JFFS与YAFFS比较,两者各有长处. 一般来说,对于小于64MBytes的NAND Flash,可以选用JFFS;如果超过64MBytes,用YAFFS比较合适.
分布式文件系统（DFS）解决方案 一“分布式文件系统（DFS）”概述 DFS并不是一种文件系统，它是Windows Server System上的一种客户/服务器模式的网络服务。它可以让把局域网中不同计算机上的不同的文件共享按照其功能组织成一个逻辑的分级目录结构。系统管理员可以利用分布式文件系统(DFS)，使用户访问和管理那些物理上跨网络分布的文件更加容易。通过DFS，可以使分布在多个服务器或者不同网络位置的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。 例如，如果您的销售资料分散在某个域中的多个存储设备上，您可以利用DFS 使其显示时就好像所有的资料都位于同一网络共享下，这样用户就不必到网络上的多个位置去查找他们需要的信息。 二部署使用“分布式文件系统（DFS）”的原因 ●访问共享文件夹的用户分布在一个站点的多个位置或多个站点上； ●大多数用户都需要访问多个共享文件夹； ●通过重新分布共享文件夹可以改善服务器的负载平衡状况； ●用户需要对共享文件夹的不间断访问；
●您的组织中有供内部或外部使用的Web 站点； ●用户访问共享文件需要权限。 三“分布式文件系统（DFS）”类型 可以按下面两种方式中的任何一种来实施分布式文件系统： 1．作为独立的分布式文件系统。 ●不使用Active Directory。 ●至多只能有一个根目录级别的目标。 ●使用文件复制服务不能支持自动文件复制。 ●通过服务器群集支持容错。 2．作为基于域的分布式文件系统。 ●必须宿主在域成员服务器上。 ●使它的DFS 名称空间自动发布到Active Directory 中。 ●可以有多个根目录级别的目标。 ●通过FRS 支持自动文件复制。 ●通过FRS 支持容错。 四分布式文件系统特性 除了Windows Server System 中基于服务器的DFS 组件外，还有基于客户的DFS 组件。DFS 客户程序可以将对DFS 根目录或DFS 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于
由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用户反馈访问慢的问题。通过排查个服务器的情况，发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，N个服务器通过nfs方式共享一个服务器的存储空间，使得 NFS服务器不堪重负。察看系统日志，全是nfs服务超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题；一旦NFS服务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我们所期待的。 下面是某个集群使用nfs共享的示意图： 这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有靠共享提供数据的应用就不再可用，尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份，但这对提高整个系统的性能毫无帮助。基于这样一种需求，我们需要对nfs服务器进行优化或采取别的解决方案，然而优化并不能对应对日益增多的客户端的性能要求，因此唯一的选择只能是采取别的解决方案了；通过调研，分布式文件系统是一个比较合适的选择。采用分布式文件系统后，服务器之间的数据访问不再是一对多的关系（1个NFS服务器，多个NFS 客户端），而是多对多的关系，这样一来，性能大幅提升毫无问题。 到目前为止，有数十种以上的分布式文件系统解决方案可供选择，如 lustre,hadoop,Pnfs等等。我尝试了 PVFS,hadoop,moosefs这三种应用，参看了lustre、KFS等诸多技术实施方法，最后我选择了moosefs（以下简称MFS）
这种分布式文件系统来作为我的共享存储服务器。为什么要选它呢？我来说说我的一些看法： 1、实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容易得多。看看lustre 700多页的pdf文档，让人头昏吧。 2、不停服务扩容。MFS框架做好后，随时增加服务器扩充容量；扩充和减少容量皆不会影响现有的服务。注：hadoop也实现了这个功能。 3、恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，原因参照第1条。 4、我在实验过程中得到作者的帮助，这让我很是感激。 MFS文件系统的组成 1、元数据服务器。在整个体系中负责管理管理文件系统，目前MFS只支持一个元数据服务器master，这是一个单点故障，需要一个性能稳定的服务器来充当。希望今后MFS能支持多个master服务器，进一步提高系统的可靠性。 2、数据存储服务器chunkserver。真正存储用户数据的服务器。存储文件时，首先把文件分成块，然后这些块在数据服务器chunkserver之间复制（复制份数可以手工指定，建议设置副本数为3）。数据服务器可以是多个，并且数量越多，可使用的“磁盘空间”越大，可靠性也越高。 3、客户端。使用MFS文件系统来存储和访问的主机称为MFS的客户端，成功挂接MFS文件系统以后，就可以像以前使用NFS一样共享这个虚拟性的存储了。 元数据服务器安装和配置
第一次挂载jffs2文件系统，出现：Node header CRC failed at 使用的bootloader：redboot kernel版本：2.6.29 flash类型：NOR FLASH. 制作jffs2的命令： mkfs.jffs2 -U -d /mnt/winF/tet/romfs -D devtable.jffs2.txt -l -e 0x10000 -p -n -o /tftpboot/jffs2fs.img "-e":表示flash的擦除块大小为0x10000,这个值很重要，可以从datasheet中得到。 "-p": Pad output to SIZE bytes with 0xFF. If SIZE is not specified, the output is padded to the end of the final erase block. 烧写命令： load -r -v -h 172.21.73.101 -b 0x8000 kernel.lzo fis create -b 0x8000 -l 0x200000 -s 0x200000 -f 0x7F060000 -e 0x8000 kernel.lzo load -r -v -h 172.21.73.101 -b 0x100000 jffs2fs.img fis write -b 0x100000 -f 0x7F260000 -l 0x250000 fis create -f 0x7F260000 -l 0x590000 jffs2.img reset 问题描述： 第一次启动，会出现CRC错误信息，如下： Shell invoked to run file: /etc/rc Welcome to ____ _ _ / __| ||_| _ _| | | | _ ____ _ _ _ _ | | | | | | || | _ \| | | |\ \/ / | |_| | |__| || | | | | |_| |/ \ | ___\____|_||_|_| |_|\____|\_/\_/ | | |_| ADVANTECH eAutomation For further information check: https://www.doczj.com/doc/0315180171.html,/ https://www.doczj.com/doc/0315180171.html,/eAutomation/ Execution Finished, Exiting Sash command shell (version 1.1.1) /> JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06ddc8.
第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备
Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式： 1. 直接通过Client实例连接到Client； 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面： 第一，数据的定位是通过CRUSH算法来实现的。
嵌入式linux下常见的文件系统RomFS：只读文件系统，可以放在ROM空间，也 可以在系统的RAM中，嵌入式linux中常用来作 根文件系统 ?RamFS：利用VFS自身结构而形成的内存文件系 统，使用系统的RAM空间 ?JFFS/JFFS2：为Flash设计的日志文件系统?Yaffs：专门为Nand Flash设计 ?proc：为内核和内核模块将信息发送给进程提 供一种机制，可以查看系统模块装载的信息?devFS：设备文件系统 Linux上的Ext2fs ?支持4 TB 存储、文件名称最长1012 字符 ?可选择逻辑块 ?快速符号链接 ?Ext2不适合flash设备 ?是为象IDE 设备那样的块设备设计的，逻辑块大小必 须是512 byte、1 KB、2KB等 ?没有提供对基于扇区的擦除／写操作的良好管理 ?如果在一个扇区中擦除单个字节，必须将整个扇区复制到RAM，然后擦除，再重写入
?在出现电源故障时，Ext2fs 是不能防止崩溃的 ?文件系统不支持损耗平衡，缩短了flash的寿命 jffs/jffs2文件系统的优缺点 ?日志文件系统 ?提供了更好的崩溃、掉电安全保护 ?jffs2支持对flash的均匀磨损 ?在扇区级别上执行闪存擦除／写／读操作要 比Ext2文件系统好 ?文件系统接近满时，JFFS2 会大大放慢运行 速度——垃圾收集 Nand上yaffs文件系统的优势 ?专门为Nand flash设计的日志文件系统 ?jffs／jffs2不适合大容量的Nand flash ?jffs的日志通过jffs_node建立在RAM中，占用RAM空间：对于128MB的Nand大概需要4MB的空间来维护节点 ?启动的时候需要扫描日志节点，不适合大容量 的Nand flash ?FAT系统没有日志 编译yaffs文件系统 ?mtd的最新补丁升级？ ?接口更新，适合与yaffs
Hadoop分布式文件系统：架构和设计要点 Hadoop分布式文件系统：架构和设计要点 原文：https://www.doczj.com/doc/0315180171.html,/core/docs/current/hdfs_design.html 一、前提和设计目标 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，不过这比较少见。
几种文件系统比较 嵌入式系统中比较常用的文件系统为JFFS、JFFS2、CRAMFS和YAFFS。 J f f s2:日志闪存文件系统版本2(J o u r n a l l i n g F l a s h F i l e S y s t e m v2) JFFS2主要应用于NOR Flash，可读写，支持数据压缩，安全保护等 特点。存储空间已满或接近满时，JFFS2文件系统的运行速度却由于垃 圾收集的原因而放慢。不适合用于NAND Flash，NAND Flash的容量一 般比较大，JFFS2文件系统为维护日志节点所占用的内存空间也迅速增大，因此JFFS2在挂载时需要很长时间来扫描整个FLASH的内容，用以找出所有的日志节点并建立文件结构，这样就会极大的降低系统的运行 效率。 y a f f s：Y e t A n o t h e r F l a s h F i l e S y s t e m yaffs/yaffs2是专为嵌入式系统使用NAND型闪存而设计的日 志型文件系统。不支持数据压缩，速度快，挂载时间很短，对内存 的占用较小。支持跨平台。yaffs/yaffs2自带NAND芯片的驱动， 并且为嵌入式系统提供了直接访问文件系统的API。yaffs仅支持 小页(512 Bytes) NAND闪存，yaffs2可支持大页(2KB) NAND闪存。 同时，yaffs2在内存空间占用、垃圾回收速度、读/写速度等方面 均有大幅提升。 C r a m f s C o m p r e s s e d R O M F i l e S y s t e m 是一种只读的压缩文件系统。它也基于MTD驱动程序。降低 了系统成本。以压缩方式存储，在运行时解压缩，不支持应用程序 以XIP方式运行，需要将程序拷到RAM里去运行，它的效率高，速 度快，其只读的特点保护文件系统免受破坏，提高了系统的可靠性。 R o m f s 文件系统是一种简单的只读文件系统，不支持动态擦写，按顺 序存放数据，因而支持应用程序以XIP片内运行方式运行，在系统 运行时，节省RAM空间。uClinux系统通常采用Romfs文件系统。 Ramdisk不是一个实际的文件系统，而是一种将实际的文件系 统装入内存的机制，并且可以作为根文件系统。Ramdisk将一些 经常被访问而又不会更改的文件放在内存中，用以提高系统的性能。 R a m f s 是基于内存的文件系统，工作于虚拟文件系统(VFS)层，不能格式化，在创建时可以指定其最大能使用的内存大小，文件系统大小可随所
分布式文件系统概述（一） 杨栋 yangdonglee@https://www.doczj.com/doc/0315180171.html, 2006-12 摘要 文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。随着网络的兴起，为了解决资源共享问题，出现了分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。本文1简要回顾了本地文件系统，然后按照发展例程大致介绍了2006年之前各时期主要的分布式文件系统，最后从设计目标、体系结构及关键技术等方面比较了各个分布式文件系统的异同。目前很火的Hadoop文件系统、S3文件系统都是从NFS等早期文件系统一步步演化而来的，了解分布式文件系统的历史，有助于大家更加深刻地领会分布式文件系统的精髓。 1本文写于2006年底，借鉴了别人的大量资料，目的是为了与同学们分享分布式文件系统的发展史。笔者在硕士期间跟随中科院计算所的孟老师、熊老师和唐荣锋进行分布式文件系统的研究和开发。分布式文件系统源远流长，本文只是选择了其发展史上的部分实例进行简单描述，由于笔者水平十分有限，错误之处难免很多，各位同学发现问题之后麻烦回复邮件到yangdonglee@https://www.doczj.com/doc/0315180171.html,，我会尽全力完善，或者请各位同学自行修正。笔者目前在百度进行云计算方面的研究和开发，希望有兴趣的同学一起进行探讨。
目录 1．引言 (5) 2．本地文件系统 (5) 2.1FFS (6) 2.2LFS (6) 2.3Ext3 (7) 3．分布式文件系统 (7) 3.1 发展历程 (7) 3.2分布式文件系统分类 (8) 3.2.1 实现方法 (8) 3.2.2研究状况 (8) 3.3 NFS (9) 3.3.1概述 (9) 3.3.2 体系结构 (9) 3.3.3 通信机制 (10) 3.3.4进程 (10) 3.3.5 命名 (10) 3.3.6 同步机制 (11) 3.3.7 缓存和复制 (11) 3.3.8 容错性 (12) 3.3.9 安全性 (13) 3.4 AFS、DFS、Coda和InterMezzo (13) 3.5 SpriteFS和Zebra (14) 3.6xFS (16) 3.6.1 概述 (16) 3.6.2 体系结构 (16) 3.6.3 通信 (16) 3.6.4 进程 (17) 3.6.5 命名 (18) 3.6.6 缓存 (19)