如果您是一位linux的初学者，建议你停下追逐的脚本，好好阅读本篇文章，linux文件系统与物理文件系统是学习linux的基础之基础，对你一定大有帮助。

    文件系统是文件的管理者，决定文件如何被操作，比如存放、打开、关闭、写入、查找。文件可以是任何格式的数据，比如音频、视频、文档、代码、图片、应用程序、快捷方式等等。因为文件各种各样，所以文件系统的存在就很必要了。比如支持新建目录，新建空白文件，显示文件大小，显示文件创建日期，这些都是文件系统提供的服务。

    文件系统结合图形操作界面，就造成了我们看到了双击就可以打开，单击就可以选中这些直观上的东西。除掉图形界面，文件系统依然可见。在linux命令行中，ls一下，会显示目录下的文件，ls -l一下，会显示文件的权限，文件的大小等等，这些都是文件系统提供支持的，如果没有文件系统，那么就没法创建文件，没法打开一个文件，我们保存在磁盘上的东西，就根本读不出来，磁盘对我们来讲就是一个谜。但是有了文件系统，我们就可以读出里面的数据。文件系统与其说是管理文件的，不如叫做磁盘驱动或者flash驱动、RAM驱动等等。没有文件系统，磁盘就是废品，没法使用。

    Linux不像windows，仅仅只支持NTFS、FAT32等几个文件系统，linux支持的文件系统特别多，比如minix文件系统，iso9660（光盘用的），ext2，ext3，ext4（目前默认文件系统），resierfs，resier4，btrfs等等。不同的设备可以使用不同的文件系统，不同的文件系统侧重点不一样，在不同方面性能不一样。但是对于用户来讲，区别这些文件系统是很困难的，于是linux内核中引入了一层虚拟文件系统。虚拟文件系统负责统一各种不同种类的文件系统对用户提供的接口，使得可以使用同样的系统调用来操作不同文件系统上的文件。

    如果我们调用open打开一个文档，那么不管这个文档存放于哪种设备上，也不管这种设备上运行的是哪种物理文件系统，都可以打开这个文件。事实上，我们没法站在用户层上区分是目前我们看到的文件是被哪种文件系统所支持的，因为linux内核的虚拟文件系统屏蔽了这些底层细节，使得不同的物理文件系统尽管管理文件的方式不同，但是用户看起来一模一样。如果想看具体究竟用得哪种文件系统，那么打开/proc/filesystems文件就可以看到目前系统中加载了多少种文件系统。

    Linux与windows除了支持的文件系统数量不一样外，还有一个明显的组织结构的区别，这使得很多人用Linux相当不习惯。Windows操作系统支持多个分区，而且这几个分区是并列关系，比如可以将磁盘分为C、D、E、F等等很多个盘，而且每个盘可以进行不同的格式化（即安装不同的文件系统）。有几个文件系统，就有几个根目录，C：是一个，D：是一个，等等。但是linux不一样，linux不管分成多少个区，都只有一个根目录。

    虚拟文件系统不存在于磁盘上，只存在于内存中。它本质上只是一种转换机制，将用户空间的请求映射到具体的物理文件系统上。物理文件系统则是实实在在的存在于磁盘中，并且占据一定的存储空间。每个文件系统都有且仅有一个超级块，该文件系统中的每个文件都有且仅有一个inode。超级块和inode都填好了数据。当你格式化一个磁盘的时候，该文件系统的超级块就已经填好了相关数据，并且占据了磁盘上的一定空间。当你新建一个文件的时候，该文件的inode中就已经记录了该文件的一切信息，比如存在磁盘哪里，建立时间，是否只读等等。

    虚拟文件系统也有自己的数据结构，典型的有四个，超级块、inode、目录项、file。但是和物理文件系统中的结构不太一样。虚拟文件系统中这些结构没有自己的数据，其数据来源于物理文件系统。系统启动的时候，根据加载了哪些文件系统，内核会用实际的物理文件系统的超级块填充内存中虚拟文件系统的超级块；inode也是根据物理文件系统中的数据填充的；目录项结构体是根据路径名现场建立的；file是打开一个文件的时候现场分配并填充的。虚拟文件系统中结构体的一切数据都来源于物理文件系统，当系统关闭的时候，物理文件系统依然待在磁盘上，虚拟文件系统则会消失。

    用户的程序实际上只和虚拟文件系统打交道，不和物理文件系统打交道。虚拟文件系统中普遍使用了内核链表这种结构体。超级块、inode、目录项、file这四大结构体都会构成双向链表。构成链表的关键在于结构体中有head_list的结构体，head_list使得不同的结构体居然也可以串成链表。有的结构体中包含多个head_list，根据不同的需求，同一数据结构会存在于多个链表中，而且同一链表中的结构体可能五花八样。

    虚拟文件系统本身只提供用户操作文件的接口，比如open函数，close函数，但是并不负责这些函数的实现，这些函数怎么实现的，即文件究竟是怎么打开的，怎么写入，怎么关闭的，是由物理文件系统提供的。同样是open，每个物理文件系统的实现函数并不一样。我在2.6.29内核中追踪了open系统调用的实现，得到了如下路径：

    Open系统调用——>sys_open函数——>do_sys_open函数——>do_filp_open函数——>nameidata_to_filp函数——>__dentry_open函数，在该函数中找到了至关重要的一句话：open = f->f_op->open;

    左边的open就是虚拟文件系统提供的open函数，右边的f_op->open则是f结构体（file类型）所在文件系统的open操作函数。这说明打开该文件的具体操作是由该文件所在文件系统提供的。

    内核代码极其复杂，追踪代码是有技巧的，如果一个函数要返回file结构，那么在它的实现代码中，最值得关注的就是同样返回file的函数，其他的函数都是旁枝末节。所以追踪代码要始终留心提供返回值的函数，它往往实现核心功能。

有关Linux系统内核文件的介绍，很基础很好的文章，供大家学习参考。

一、vmlinuz
vmlinuz是可引导的、压缩的内核。"vm"代表"Virtual Memory".Linux 支持虚拟内存，不像老的操作系统比如DOS有640KB内存的限制。Linux能够使用硬盘空间作为虚拟内存，因此得名"vm".vmlinuz是可执行的Linux内核，它位于/boot/vmlinuz,它一般是一个软链接。

vmlinuz的建立有两种方式。一是编译内核时通过"make zImage"创建，然后通过：
"cp /usr/src/linux-2.4/arch/i386/linux/boot/zImage /boot/vmlinuz"产生。zImage适用于小内核的情况，它的存在是为了向后的兼容性。二是内核编译时通过命令make bzImage创建，然后通过："cp /usr/src/linux-2.4/arch/i386/linux/boot/bzImage /boot/vmlinuz"产生。bzImage是压缩的内核映像，需要注意，bzImage不是用bzip2压缩的，bzImage中的bz容易引起误解，bz表示"big zImage". bzImage中的b是"big"意思。

zImage（vmlinuz）和bzImage（vmlinuz）都是用gzip压缩的。它们不仅是一个压缩文件，而且在这两个文件的开头部分内嵌有gzip解压缩代码。所以你不能用gunzip 或 gzip –dc解包vmlinuz.

内核文件中包含一个微型的gzip用于解压缩内核并引导它。两者的不同之处在于，老的zImage解压缩内核到低端内存（第一个640K），bzImage解压缩内核到高端内存（1M以上）。如果内核比较小，那么可以采用zImage 或bzImage之一，两种方式引导的系统运行时是相同的。大的内核采用bzImage,不能采用zImage.

vmlinux是未压缩的内核，vmlinuz是vmlinux的压缩文件。

二、 initrd-x.x.x.img
initrd是"initial ramdisk"的简写。initrd一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。比如，使用的是scsi硬盘，而内核vmlinuz中并没有这个scsi硬件的驱动，那么在装入scsi模块之前，内核不能加载根文件系统，但scsi模块存储在根文件系统的/lib/modules下。为了解决这个问题，可以引导一个能够读实际内核的initrd内核并用initrd修正scsi引导问题。initrd-2.4.7-10.img是用gzip压缩的文件，下面来看一看这个文件的内容。

initrd实现加载一些模块和安装文件系统等。

initrd映象文件是使用mkinitrd创建的。mkinitrd实用程序能够创建initrd映象文件。这个命令是RedHat专有的。其它Linux发行版或许有相应的命令。这是个很方便的实用程序。具体情况请看帮助：man mkinitrd

下面的命令创建initrd映象文件：

三、 System.map
System.map是一个特定内核的内核符号表。它是你当前运行的内核的System.map的链接。

内核符号表是怎么创建的呢？ System.map是由"nm vmlinux"产生并且不相关的符号被滤出。对于本文中的例子，编译内核时，System.map创建在/usr/src/linux-2.4/System.map.像下面这样：
nm /boot/vmlinux-2.4.7-10 > System.map

下面几行来自/usr/src/linux-2.4/Makefile:
nm vmlinux | grep -v '（compiled）|（。o$$）|（ [aUw] ）|（ng$$）|（LASH[RL]DI）' | sort > System.map

然后复制到/boot:
cp /usr/src/linux/System.map /boot/System.map-2.4.7-10

在进行程序设计时，会命名一些变量名或函数名之类的符号。Linux内核是一个很复杂的代码块，有许许多多的全局符号。

Linux内核不使用符号名，而是通过变量或函数的地址来识别变量或函数名。比如不是使用size_t BytesRead这样的符号，而是像c0343f20这样引用这个变量。

对于使用计算机的人来说，更喜欢使用那些像size_t BytesRead这样的名字，而不喜欢像c0343f20这样的名字。内核主要是用c写的，所以编译器/连接器允许我们编码时使用符号名，当内核运行时使用地址。

然而，在有的情况下，我们需要知道符号的地址，或者需要知道地址对应的符号。这由符号表来完成，符号表是所有符号连同它们的地址的列表。Linux 符号表使用到2个文件：
/proc/ksyms
System.map

/proc/ksyms是一个"proc file",在内核引导时创建。实际上，它并不真正的是一个文件，它只不过是内核数据的表示，却给人们是一个磁盘文件的假象，这从它的文件大小是0可以看出来。然而，System.map是存在于你的文件系统上的实际文件。当你编译一个新内核时，各个符号名的地址要发生变化，你的老的System.map具有的是错误的符号信息。每次内核编译时产生一个新的System.map,你应当用新的System.map来取代老的System.map.

虽然内核本身并不真正使用System.map,但其它程序比如klogd, lsof和ps等软件需要一个正确的System.map.如果你使用错误的或没有System.map,klogd的输出将是不可靠的，这对于排除程序故障会带来困难。没有System.map,你可能会面临一些令人烦恼的提示信息。

另外少数驱动需要System.map来解析符号，没有为你当前运行的特定内核创建的System.map它们就不能正常工作。

Linux的内核日志守护进程klogd为了执行名称-地址解析，klogd需要使用System.map.System.map应当放在使用它的软件能够找到它的地方。执行：man klogd可知，如果没有将System.map作为一个变量的位置给klogd,那么它将按照下面的顺序，在三个地方查找System.map:
/boot/System.map
/System.map
/usr/src/linux/System.map

System.map也有版本信息，klogd能够智能地查找正确的映象（map）文件。

设置linux系统时间
[root@localhost ~]# date -s 17:08:50

设置CMOS时间。强制把系统时间写入CMOS。
[root@localhost ~]# clock -w

在系统启动时，Linux操作系统将时间从CMOS中读到系统时间变量中，以后修改时间通过修改系统时间实现。为了保持系统时间与CMOS时间的一致性，Linux每隔一段时间（大约是11分钟）会将系统时间写入CMOS。由于该同步是每隔一段时间进行的，在我们执行date -s后，如果马上重起机器，修改时间就有可能没有被写入CMOS,这就是问题的原因。如果要确保修改生效可以执行clock -w命令。

与时间同步服务器进行同步, 国家授时中心服务器的IP地址(210.72.145.44)
[root@hn ~]# ntpdate 210.72.145.44

linux下设置时间同步服务器（NTP）
可以从时间服务器 time.nist.gov 同步。

在crontab中加入：
00 0 1 * * root rdate -s time.nist.gov

您可能感兴趣的文章：
linux下修改时间的方法分享
linux下调整时区与时间的方法详解
linux 时间与时区修改方法
linux 时间同步的两种方法
linux 下手动修改时间的方法
修改Linux时间与时区的方法
linux下更改时间的方法
linux下修改时间与时区的方法
Linux 修改时间的方法
linux 查看设置时区和时间
Linux或Unix修改系统时间的方法