Google文件系统--GFS详解

  Google File System(简称GFS)是适用于大规模且可扩展的分布式文件系统，可以部署在廉价的商务服务器上，在保证系统可靠性和可用 性的同时，大大降低了系统的成本。GFS的设计目标是高性能、高可靠、高可用性。

  GFS把机器故障视为正常现象，可以很好地处理系统故障。GFS系统通常会部署在上百台甚至上千台廉价服务器上，并会有相当多台廉价服务器上部署GFS Client来访问GFS服务，所以应用故障、 *** 作系统bug、连接故障、网络故障、甚至机器供电故障都是经常发生的故障。GFS系统可以支持系统监控、故障检测、故障容忍和自动恢复，提供了非常高的可靠性。其次，GFS系统中的文件一般都是大文件，且文件 *** 作大部分场景下都是append而不是overwrite。一旦文件写入完成后，大部分 *** 作都是读文件且是顺序读。

  GFS提供了非标准（比如POSIX）的文件系统接口，支持 create、delete、open、close、read以及write。另外GFS支持snapshot和record append *** 作。snapshot可以以很低的代价创建文件或者目录树的拷贝，record append可以支持多个client并发地向同一个文件append data，同时还能保证每个client的append *** 作的原子性。

  master记录了文件系统的metadata，包括名字空间、权限控制信息、文件到chunk的mapping以及chunk的分布。master也负责chunk的lease管理、无用chunk的垃圾回收、chunk迁移等。master定期与chunkserver通信，向chunkserver发送指令并搜集chunkserver的状态。GFS client通过GFS的API与GFS系统通信（读写数据）。client向master请求获取metadata，真正的读写数据是直接与chunkserver交互。client和chunkserver都不cache文件数据。因为大部分应用都是基于API来streaming read 大文件且系统的文件数据太多，所以client缓存文件数据没有意义。chunkserver所在机器的Linux的buffer cache以及cache了频繁访问的数据，chunkserver也是没有去cache文件数据的。

  单点master大大简化了系统设计，因为master知晓所有的meta信息，所以可以执行更加复杂的chunk位置分配和副本策略。但是，在读写数据时必须降低master的参与，以避免单点的master称为系统瓶颈。client不会通过master来读写文件数据，但是client会向master发送查询chunk位置分布的请求，然后client端缓存chunk的分布信息，然后直接向chunkserver读写数据。大致的读过程如下：

1、client根据文件名、byte offset以及chunk size计算出要读取的文件的chunk index

2、client通过文件名、chunk index向master查询chunk的分布

3、master回复chunk handler以及副本分布

4、client 缓存chunk的meta信息，key由文件名和chunk index组成

5、client从chunk的分布信息中查找距离自己最新的chunkserver，并发送查询请求。查询请求中包括chunk hander以及byte range。后续对相同chunk的查询不需要再次向master查询meta信息，因为client已经缓存了meta信息。

  chunk size是GFS系统的关键参数，通常设置为64MB，远大于文件系统的block大小。每个chunk的副本都chunkserver所在机器上以Linux file存储。之所为将chunk size定为64MB，主要有以下考虑：

1、可以减少client访问master查询meta信息的次数，降低master的访问压力。因为chunk size设计比较大，顺序访问一个超大文件时因为chunk数较少且client缓存了chunk meta信息，所以访问master的次数就会降低。甚至，client可以缓存所有文件的chunk的meta信息，就算是随机读文件，master也不会成为系统性能瓶颈。

2、可以减少网络开销，保持client与chunkserver的TCP连接，可以执行更多的chunk *** 作。

3、可以减少master上需要在内存中记录的meta data数据量，降低master的内存占用。

   size大的缺点是：小文件包含很少的chunk，甚至只有一个。这样的话，在多个client高并发查询该小文件时对应的chunk会成为热点。实际上，这种情况在GFS系统中很少发生，因为大部分client的 *** 作都是顺序读大文件。但是，考虑以下场景，我们部署一个服务的二进制文件到GFS系统中，然后数百台的服务器同时查询二进制文件并启动服务，此时该二进制文件副本所在的chunkserver立马就会成为查询瓶颈。当然，可以通过增加副本数和分散服务器的查询时间来解决这种场景下的问题。

  master主要存储三种类型的metadata：file和chunk的名字空间，file到chunk的mapping信息以及chunk的副本分布。所有的metadata都在master的内存中存储。前两种meta信息可以持久化存储，将 *** 作日志存储在master的本地磁盘以及将备份日志存储在远端机器上。master不持久化存储chunk的副本分布信息，而是通过与chunkserver交互来获取chunkserver上的chunk信息。

4.1 in-memory data structure

  meta信息在内存中，所有master的 *** 作很快。另外，master可以高效地定期在后台scan所有的meta数据，来执行垃圾回收、副本修复、均衡等。metadata都记录在内存中，所以GFS系统会比较关注chunk的数量以及master的可用内存量。但是在实际场景下，这不是问题。每个64MB的chunk的metadata小于64字节，大部分的chunk都是满负荷存储的，除了文件最后一个chunk的空间是没有完全被占用。由于文件的名字空间采用了前缀压缩的方式存储，单个文件的meta信息也是小于64字节。如果需要扩大系统规模的话，可以很简单地通过增大master的内存就可以了。相比于系统的高可靠、高性能和简洁性，增加内存是很最小的代价了。

4.2 chunk 分布

  并没有持久化存储chunk的副本分布信息，而是在master启动时向chunkserver查询其chunk信息，然后通过heartbeat来持续更新master的副本分布信息，以与chunkserver数据保持一致。GFS起初设计时尝试将chunk的分布信息持久化存储在master端，随后发现通过master启动时拉取然后通过heartbeat同步chunk信息的方式更简单。因为，当chunkserver加入、退出、名字改变、重启等行为经常发生，这会导致维护master的chunk meta数据的正确性是非常困难的。从另一个角度考虑就是，只有chunkserver汇报的chunk信息才是集群中最真实的chunk分布，因为master不需要自己维护一个chunk分布状态，只需要以chunkserver的状态汇报为准即可。

4.3 *** 作日志

  日志记录了GFS集群数据更改的历史记录。 *** 作日志对GFS来说是至关重要的，因为它不仅是metadata的持久化记录，还记录了并发 *** 作的时序。因为 *** 作日志很重要，所以必须可靠地存储。在metadata的change没有持久化之前，client是不能看到的数据的更改。当client修改数据时， *** 作记录需要保存在多个远端机器上，而且只有当 *** 作记录持久化存储在本地和远端以后，才会回复client数据更改成功。

  可以通过回放 *** 作日志来恢复文件系统。为了减少系统启动时replay的时间，必须缩减回放的日志量。master可以定期存储metadata的checkpoint，master重启时可以从checkpoint加载metadata，然后回放checkpoint之后的少量日志即可。

1、client向master查询chunk的primary所在的chunkserver以及其他副本的分布，如果没有primary的花，master会选择一个作为该chunk的primary

2、master回复client primary和其他副本的分布信息。client会cache返回的metadata

3、client将数据发送所有的副本。client可以以任意顺序执行。每个chunkserser都会在内存的LRUbuffer中记录数据。

4、当所有的副本都返回已经接收数据成功后，client会向primary发送一个写请求。primary会为每一个数据更改的请求附加一个序列号，数据更改是按照序列号的顺序执行的。

5、primary将数据更改同步到其他副本中，副本也是按照序列号执行数据更改 *** 作。

6、primary接收到其他副本回复的数据 *** 作完成

7、primary返回client结果。期间发生的所有错误都会报给client。

   GFS集群一般都会有上百台的chunkserver，分布在多个机架上。chunkserver也会接收来自本机架或者其他机架的上百个client的查询请求。不同机架的服务器通信可能会途径一个或者多个交换机转发。chunk的副本分布选择策略主要目的是尽量提高数据的可靠性和可用性，同时最大化地充分利用网络带宽。所以，仅仅将副本跨机器部署是不够的。GFS将副本是跨机架部署的，这样可以保证在一个机架被损坏或者下线时，chunk至少会有副本是可用的。

   chunk的副本在下列情况下会被创建：创建chunk、副本修复、rebalance。当master创建chunk时，会选择存储该chunk副本的chunkserver。主要考虑以下几点：

1、新副本所在chunkserver的磁盘利用率低于系统的平均水平

2、限制每个chunkserver最近一段时间创建chunk的数量

3、每个chunk的所有副本不能都在一个机架

   chunk的副本数少于一定数量是，master会复制一个副本。这可能发生在chunkserver宕机或者chunkserver汇报自己的副本损坏或者chunkserver所在机器的磁盘损坏等等。每个chunk 复制任务都有优先级，按照优先级由高到低子master中排队等待执行。master还会定期扫描当前副本的分布情况，一旦发现磁盘使用量或者机器负载不均衡，就会发起负载均衡 *** 作。无论是chunk创建、chunk复制还是负载均衡，选择chunk副本的位置的策略都是相同的，并且需要限制副本修复和均衡的速度，否则会影响系统的正常读写服务。

  Google的成功表明单master的设计师可行的。这不仅简化了系统，而且能够较好地实现一致性，给予性能考虑，GFS提出了“记录至少原子性追加一次”的一致性模型。通过租约的方式将每个chunk的修改授权到chunkserver从而减少了master的负载，通过流水线的方式复制多个副本以减少延时。master维护的元数据很多，需要设计高效的数据结构，且要保证占用内存小和支持快照 *** 作。支持COW的B树可以满足需求，但是实现确实相当复杂。

分类: 电脑/网络

问题描述:

FAT32与NTFS各有什么特点?

解析:

---------先了解FAT/FAT16/FAT32---------

在推出FAT32文件系统之前，通常PC机使用的文件系统是FAT16。像基于MS-DOS，Win 95等系统都采用了FAT16文件系统。在Win 9X下，FAT16支持的分区最大为2GB。我们知道计算机将信息保存在硬盘上称为“簇”的区域内。使用的簇越小，保存信息的效率就越高。在FAT16的情况下，分区越大簇就相应的要增大，存储效率就越低，势必造成存储空间的浪费。并且随着计算机硬件和应用的不断提高，FAT16文件系统已不能很好地适应系统的要求。在这种情况下，推出了增强的文件系统FAT32。同FAT16相比，FAT32主要具有以下特点：

1. 同FAT16相比FAT32最大的优点是可以支持的磁盘大小达到2TB（2047GB），但是不能支持小于512MB的分区。基于FAT32的Win 2000可以支持分区最大为32GB；而基于 FAT16的Win 2000支持的分区最大为4GB。

2. 由于采用了更小的簇，FAT32文件系统可以更有效率地保存信息。如两个分区大小都为2GB，一个分区采用了FAT16文件系统，另一个分区采用了FAT32文件系统。采用FAT16的分区的簇大小为32KB，而FAT32分区的簇只有4KB的大小。这样FAT32就比FAT16的存储效率要高很多，通常情况下可以提高15%。

3. FAT32文件系统可以重新定位根目录和使用FAT的备份副本。另外FAT32分区的启动记录被包含在一个含有关键数据的结构中，减少了计算机系统崩溃的可能性。

◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎

NTFS 和 FAT32 分区的区别到底是啥呢？？？

inbase/home/printpage?ArticleID=583

当然了NTFS 和 FAT32 都是目前比较流行的磁盘分区格式，由FAT到FAT16----FAT32---NTFS，NTFS功能强一些。

1. NTFS 支持文件加密和分别管理功能（也就是著名的EFS加密格式），可为用户提供更高层次的安全保证。

2. NTFS 具有更好的磁盘压缩性能，可进一步满足小硬盘用户的需要（读取会慢一些）。

3. NTFS 最大支持高达 2TB （1TB＝1024GB)的大硬盘，而且它的性能不会随着磁盘容量的增大而降低。

由此可见，NTFS 格式具有许多独特的优点

不过，呵呵，它也有一个缺点，那就是该磁盘文件格式不能被除它自己之外的其他 *** 作系统所识别（NT 4.0也不例外），这就对数据交流造成了一定的影响，也就不支持DOS *** 作系统了，不过还是值得支持。

所以呀....只使用 Windows 2000 的用户应首选使用 NTFS 格式，要是同时使用 Windows 2000 和其他 *** 作系统，则应谨慎从事。最好将磁盘划分为多个不同的磁盘分区，将 Windows 2000 安装到其中的一个磁盘分区并选择使用 NTFS 格式；将其他 *** 作系统安装到另外的磁盘分区中并使用 FAT 或 FAT32 格式。

NTFS文件系统（下有详解）

NTFS文件系统是一个基于安全性的文件系统，是Windows NT所采用的独特的文件系统结构，它是建立在保护文件和目录数据基础上，同时照顾节省存储资源、减少磁盘占用量的一种先进的文件系统。使用非常广泛的Windows NT 4.0采用的就是NTFS 4.0文件系统（下面讲的是5.0，不好意思，哈哈），相信它所带来的强大的系统安全性一定给广大用户留下了深刻的印象。Win 2000采用了更新版本的NTFS文件系统NTFS 5.0，它的推出使得用户不但可以像Win 9X那样方便快捷地 *** 作和管理计算机，同时也可享受到NTFS所带来的系统安全性。

◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎◎

注意了！！！！！1

－－－－－－－－－－再看一下NTFS－－－－－－－

NTFS 5.0的特点主要体现在以下几个方面：

1. NTFS可以支持的分区(如果采用动态磁盘则称为卷)大小可以达到2TB。而Win 2000中的FAT32支持分区的大小最大为32GB。

2. NTFS是一个可恢复的文件系统。在NTFS分区上用户很少需要运行磁盘修复程序。NTFS通过使用标准的事物处理日志和恢复技术来保证分区的一致性。发生系统失败事件时，NTFS使用日志文件和检查点信息自动恢复文件系统的一致性。

3. NTFS支持对分区、文件夹和文件的压缩。任何基于Windows的应用程序对NTFS分区上的压缩文件进行读写时不需要事先由其他程序进行解压缩，当对文件进行读取时,文件将自动进行解压缩；文件关闭或保存时会自动对文件进行压缩。

4. NTFS采用了更小的簇,可以更有效率地管理磁盘空间。在Win 2000的FAT32文件系统的情况下,分区大小在2GB～8GB时簇的大小为4KB；分区大小在8GB～16GB时簇的大小为8KB；分区大小在16GB～32GB时,簇的大小则达到了16KB。而Win 2000的NTFS文件系统，当分区的大小在2GB以下时,簇的大小都比相应的FAT32簇小当分区的大小在2GB以上时(2GB～2TB),簇的大小都为4KB。相比之下，NTFS可以比FAT32更有效地管理磁盘空间，最大限度地避免了磁盘空间的浪费。

5. 在NTFS分区上,可以为共享资源、文件夹以及文件设置访问许可权限。许可的设置包括两方面的内容：一是允许哪些组或用户对文件夹、文件和共享资源进行访问；二是获得访问许可的组或用户可以进行什么级别的访问。访问许可权限的设置不但适用于本地计算机的用户,同样也应用于通过网络的共享文件夹对文件进行访问的网络用户。与FAT32文件系统下对文件夹或文件进行访问相比，安全性要高得多。另外,在采用NTFS格式的Win 2000中,应用审核策略可以对文件夹、文件以及活动目录对象进行审核，审核结果记录在安全日志中，通过安全日志就可以查看哪些组或用户对文件夹、文件或活动目录对象进行了什么级别的 *** 作，从而发现系统可能面临的非法访问,通过采取相应的措施，将这种安全隐患减到最低。这些在FAT32文件系统下,是不能实现的。

6. 在Win 2000的NTFS文件系统下可以进行磁盘配额管理。磁盘配额就是管理员可以为用户所能使用的磁盘空间进行配额限制，每一用户只能使用最大配额范围内的磁盘空间。设置磁盘配额后，可以对每一个用户的磁盘使用情况进行跟踪和控制，通过监测可以标识出超过配额报警阈值和配额限制的用户，从而采取相应的措施。磁盘配额管理功能的提供，使得管理员可以方便合理地为用户分配存储资源，避免由于磁盘空间使用的失控可能造成的系统崩溃，提高了系统的安全性。

7. NTFS使用一个“变更”日志来跟踪记录文件所发生的变更。

小提示(选取FAT32和NTFS的建议)

在系统的安全性方面，NTFS文件系统具有很多FAT32文件系统所不具备的特点，而且基于NTFS的Win 2000运行要快于基于FAT32的Win 2000；而在与Win 9X的兼容性方面，FAT32优于NTFS。所以在决定Win 2000中采用什么样的文件系统时应从以下几点出发：

1. 计算机是单一的Win 2000系统，还是采用多启动的Win 2000系统；

2. 本地安装的磁盘的个数和容量；

3. 是否有安全性方面的考虑等。

基于以上的考虑，如果要在Win 2000中使用大于32GB的分区的话，那么只能选择NTFS格式。如果计算机作为单机使用，不需要考虑安全性方面的问题，更多地注重与Win 9X的兼容性，那么FAT32是最好的选择。如果计算机作为网络工作站或更多的追求系统的安全性，而且可以在单一的Win 2000模式下运行，强烈建议所有的分区都采用NTFS格式；如果要兼容以前的应用，需要安装Win 9X或其它的 *** 作系统，建议做成多启动系统，这就需要两个以上的分区，一个分区采用NTFS格式，另外的分区采用FAT32格式，同时为了获得最快的运行速度建议将Win 2000的系统文件放置在NTFS分区上，其它的个人文件则放置在FAT32分区中。

Linux的文件和目录组织是一个单根的倒置的树状结构，文件系统从根目录下开始，用"/"表示，我们也可称为根文件系统(rootfs),这样的根文件系统，有以下特性：

（1） 文件名称区分大小写

（2） 以.开头的文件为隐藏文件

（3） 以/作为路径分隔符

在Linux各大发行版中它们的文件和目录组织其实是遵循FHS（Filesystem Hierarchy Standard）标准，FHS定义了系统中每个目录的用途。FHS有2层规范，第一层里定义了/下的各个目录应该要放什么数据。第2层则是针对/usr及/var这2个目录的子目录来定义。最新版本FHS2.3，大致内容如下表所示：

各大发行版除了遵循基本的LFS之外，也可以追加自己的目录结构，形成自己的风格；例如：在Ubuntu中网卡配置文件是存放在/etc/network/目录下，CentOS是在/etc/sysconfig/network-scripts/目录下。CentOS系统一些重要的目录及其基本用途如下图所示：

CentOS7之后bin,lib,lib64,sbin合并到/usr/bin,/usr/lib/,/usr/lib64,/usr/sbin里了。

---