day three

1、Namenode
Namenode是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表, 接收用户的操作请求。
文件包括：
①fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
②edits:操作日志文件。
③fstime:保存最近一次checkpoint的时间
以上这些文件是保存在linux的文件系统中。通过hdfs-site.xml的dfs.namenode.name.dir属性进行设置。

查看NameNode的fsimage与edits内容
这个两个文件中的内容使用普通文本编辑器是无法直接查看的，幸运的是hadoop为此准备了专门的工具用于查看文件的内容，这些工具分别为oev和oiv，可以使用hdfs调用执行。

2、Datanode
提供真实文件数据的存储服务。
文件块（ block）： 最基本的存储单位。
对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。 HDFS默认Block大小是128MB， 因此，一个256MB文件，共有256/128=2个Block.
与普通文件系统不同的是，在 HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。
Replication：多复本。默认是三个。通过hdfs-site.xml的dfs.replication属性进行设置。

2.元数据块

元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录，为了达到编制目录的目的，必须在描述并收藏数据的内容或特色，进而达成协助数据检索的目的。都柏林核心集（Dublin Core Metadata Initiative，DCMI）是元数据的一种应用，是1995年2月由国际图书馆电脑中心（OCLC）和美国国家超级计算应用中心（National Center for Supercomputing Applications，NCSA）所联合赞助的研讨会，在邀请52位来自图书馆员、电脑专家，共同制定规格，创建一套描述网络上电子文件之特征。

3.数据块

数据块是一组或几组按顺序连续排列在一起的记录，是主存储器与输入设备、输出设备或外存储器之间进行传输的数据单位。

数据块是一组按顺序连续排列在一起的几组记录，是主存储器与输入、输出设备或外存储器之间进行传输的一个数据单位。是数据的物理记录，与数据的逻辑记录（逻辑上有联系，在存储器上占有一组邻接单元的数据单位）之间的对应关系有3种方式：①一个块即为一个记录；②一个块包含若干个逻辑记录；③一个逻辑记录占有几个块。数据块的大小可以是固定的或是可变的，块与块之间有间隙。设计数据块大小，受到多方面因素的影响，包括输入、输出效率，存储空间代价以及计算机应用特点等。

主存与cache都划分成长度相等的数据块，每次主存与cache交换数据时都是以数据块为单位进行的。^[1] 

在SQL Server中：

在 text 、ntext 和 image 数据中，数据块是应用程序和 SQL Server实例之间一次传输的数据单元。该术语还适用于这些数据类型的存储单元。在磁带备份文件中，数据块是物理 I/O 的单元。

机制mechanism，策略policy。如果你看过《linux device drivers》，里面给出了大概的介绍。机制提供了干什么(do what),策略提供如何做（how to do）。驱动程序完成机制的功能，把策略的实现留给用户的应用程序。

       通常在机制中，驱动程序要完成打开，关闭，读写，控制等功能。这些都是设备使用时最基本的操作。而策略中就要实现一些高级的数据处理或界面功能。通过例子来说明会更好些。

       以RTC（实时时钟设备）为例。假设RTC共有8个REG，分别是2个控制寄存器、年寄存器、月寄存器、日寄存器、时寄存器、分寄存器、秒寄存器。RTC的启动和关闭分别通过设定控制寄存器的某一个位来完成。

       1.    驱动程序提供open,release,write,read函数。Open和release不多说了，具体介绍一下read和write的功能。Read中通过IO端口操作可以读入这8个寄存器的值，Write中通过IO端口操作可以写入这8个寄存器的值。仅仅这样驱动程序已经为应用程序提供了所有完成对RTC设备访问的接口。这样或许对应用程序操作RTC不是很方便，因此在发布驱动程序的时候，我们提供了针对RTC的用户函数库。比如setDate,setTime等，这些函数无非就是把驱动程序中的read和write组合调用了一下。但是采用这种策略，用户写应用程序时就会更方便，对底层的细节就不必知道的太多。

       2.    另一个可以选择的机制就是驱动程序中引入ioctl函数，驱动程序把setDate,setTime操作的功能在ioctl函数中实现。Ioctl通过IO端口操作访问8个寄存器就可以完成。将来驱动程序发布时，不用提供用户函数库。只要告诉开发人员IOCTL函数的操作码即可，使用不同的ioctl调用就可以完成setDate,setTime功能。

      通过上面两种情况可以看出，机制不同提供的策略选择不同，机制可以把策略中的一些功能集成。但是如何选择正确的机制和策略组合呢？

      针对上面2中机制提供，分析各自优缺点：

      第一种方案中，由于没有提供Ioctl函数，驱动程序必然会占用内存小。而且对于RTC设备，我们不会经常去setDate,setTime，因此这种小概率使用的函数放到用户库中实现更好。

      第二中方案，不用提供用户函数库，发布方便。但是ioctl函数会常驻内存中，尽管他可能一直得不到调用！这中方式更符合面向对象的编程思想。