linux位图

㈠ 程序员必备知识（操作系统5-文件系统）

本篇与之前的第三篇的内存管理知识点有相似的地方

对于运行的进程来说，内存就像一个纸箱子, 仅仅是一个暂存数据的地方， 而且空间有限。如果我们想要进程结束之后，数据依然能够保存下来，就不能只保存在内存里，而是应该保存在 外部存储 中。就像图书馆这种地方，不仅空间大,而且能够永久保存。

我们最常用的外部存储就是 硬盘 ，数据是以文件的形式保存在硬盘上的。为了管理这些文件，我们在规划文件系统的时候，需要考虑到以下几点。

第一点,文件系统要有严格的组织形式，使得文件能够 以块为单位进行存储 。这就像图书馆里，我们会给设置一排排书架，然后再把书架分成一个个小格子，有的项目存放的资料非常多，一个格子放不下，就需要多个格子来进行存放。我们把这个区域称为存放原始资料的 仓库区 。

第二点,文件系统中也要有 索引区 ，用来方便查找一个文件分成的多个块都存放在了什么位置。这就好比，图书馆的书太多了,为了方便查找,我们需要专门设置一排书架,这里面会写清楚整个档案库有哪些资料,资料在哪个架子的哪个格子上。这样找资料的时候就不用跑遍整个档案库,在这个书架上找到后，直奔目标书架就可以了。

第三点,如果文件系统中有的文件是热点文件,近期经常被读取和写入，文件系统应该有 缓存层 。这就相当于图书馆里面的热门图书区,这里面的书都是畅销书或者是常常被借还的图书。因为借还的次数比较多,那就没必要每次有人还了之后，还放回遥远的货架，我们可以专门开辟一个区域, 放置这些借还频次高的图书。这样借还的效率就会提高。

第四点,文件应该用 文件夹 的形式组织起来，方便管理和查询。这就像在图书馆里面，你可以给这些资料分门别类,比如分成计算机类.文学类.历史类等等。这样你也容易管理，项目组借阅的时候只要在某个类别中去找就可以了。

在文件系统中，每个文件都有一个名字,这样我们访问一个文件，希望通过它的名字就可以找到。文件名就是一个普通的文本。 当然文件名会经常冲突,不同用户取相同的名字的情况还是会经常出现的。

要想把很多的文件有序地组织起来,我们就需要把它们成为 目录 或者文件夹。这样,一个文件夹里可以包含文件夹,也可以包含文件,这样就形成了一种 树形结构 。而我们可以将不同的用户放在不同的用户目录下，就可以一定程度上避免了命名的冲突问题。

第五点，linux 内核要在自己的内存里面维护一套数据结构，来保存哪些文件被哪些进程打开和使用 。这就好比，图书馆里会有个图书管理系统，记录哪些书被借阅了，被谁借阅了，借阅了多久,什么时候归还。

文件系统是操作系统中负责管理持久数据的子系统，说简单点,就是负责把用户的文件存到磁盘硬件中,因为即使计算机断电了，磁盘里的数据并不会丢失,所以可以持久化的保存文件。

文件系统的基本数据单位是 文件 ，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同,就会形成不同的文件系统。

Linux最经典的一句话是:“一切皆文件”,不仅普通的文件和目录，就连块设备、管道、socket 等，也都是统一交给文件系统管理的。

Linux文件系统会为每个文件分配两个数据结构: 索引节点(index node) 和 目录项(directory entry) ，它们主要用来记录文件的元信息和目录层次结构。

●索引节点，也就是inode, 用来记录文件的元信息，比如inode编号、文件大小访问权限、创建时间、修改时间、 数据在磁盘的位置 等等。 索引节点是文件的唯一标识 ,它们之间一一对应, 也同样都会被 存储在硬盘 中,所以索引节点同样占用磁盘空间。

●目录项，也就是dentry, 用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，就会形成 目录结构 ，但它与索引节点不同的是,目录项是由内核维护的一个数据结构,不存放于磁盘，而是 缓存在内存 。

由于索引节点唯一标识一个文件，而目录项记录着文件的名，所以目录项和索引节点的关系是多对一,也就是说，一个文件可以有多个别字。比如，硬链接的实现就是多个目录项中的索引节点指向同一个文件。

注意，目录也是文件，也是用索引节点唯一标识，和普通文件不同的是，普通文件在磁盘里面保存的是文件数据，而目录文件在磁盘里面保存子目录或文件。

（PS：目录项和目录不是一个东西！你也不是一个东西（^_=）， 虽然名字很相近，但目录是个文件。持久化存储在磁盘,而目录项是内核一个数据结构,缓存在内存。

如果查询目录频繁从磁盘读，效率会很低，所以内核会把已经读过的目录用目录项这个数据结构缓存在内存，下次再次读到相同的目录时，只需从内存读就可以,大大提高了 文件系统的效率。

目录项这个数据结构不只是表示目录，也是可以表示文件的。）

磁盘读写的最小单位是 扇区 ，扇区的大小只有512B大小，很明显，如果每次读写都以这么小为单位，那这读写的效率会非常低。

所以，文件系统把多个扇区组成了一个 逻辑块 ，每次读写的最小单位就是逻辑块(数据块) , Linux中的逻辑块大小为4KB,也就是一次性读写 8个扇区,这将大大提高了磁盘的读写的效率。

以上就是索引节点、目录项以及文件数据的关系，下面这个图就很好的展示了它们之间的关系:

索引节点是存储在硬盘上的数据，那么为了加速文件的访问，通常会把索引节点加载到内存中。

另外，磁盘进行格式化的时候，会被分成三个存储区域，分别是超级块、索引节点区和数据块区。

●超级块,用来存储文件系统的详细信息，比如块个数、块大小、空闲块等等。

●索引节点区,用来存储索引节点;

●数据块区，用来存储文件或目录数据;

我们不可能把超级块和索引节点区全部加载到内存,这样内存肯定撑不住，所以只有当需要使用的时候，才将其加载进内存，它们加载进内存的时机是不同的.

●超级块:当文件系统挂载时进入内存;

●索引节点区:当文件被访问时进入内存;

文件系统的种类众多，而操作系统希望 对用户提供一个统一的接口 ，于是在用户层与文件系统层引入了中间层，这个中间层就称为 虚拟文件系统(Virtual File System, VFS) 。

VFS定义了一组所有文件系统都支持的数据结构和标准接口,这样程序员不需要了解文件系统的工作原理，只需要了解VFS提供的统一接口即可。

在Linux文件系统中，用户空间、系统调用、虚拟机文件系统、缓存、文件系统以及存储之间的关系如下图:

Linux支持的文件系统也不少，根据存储位置的不同，可以把文件系统分为三类:

●磁盘的文件系统，它是直接把数据存储在磁盘中,比如Ext 2/3/4. XFS 等都是这类文件系统。

●内存的文件系统，这类文件系统的数据不是存储在硬盘的,而是占用内存空间，我们经常用到的/proc 和/sys文件系统都属于这一类,读写这类文件,实际上是读写内核中相关的数据。

●网络的文件系统,用来访问其他计算机主机数据的文件系统，比如NFS. SMB等等。

文件系统首先要先挂载到某个目录才可以正常使用，比如Linux系统在启动时,会把文件系统挂载到根目录。

在操作系统的辅助之下，磁盘中的数据在计算机中都会呈现为易读的形式，并且我们不需要关心数据到底是如何存放在磁盘中,存放在磁盘的哪个地方等等问题，这些全部都是由操作系统完成的。

那么，文件数据在磁盘中究竟是怎么样的呢?我们来一探究竟!

磁盘中的存储单元会被划分为一个个的“ 块 ”，也被称为 扇区 ,扇区的大小一般都为512byte.这说明即使一块数据不足512byte,那么它也要占用512byte的磁盘空间。

而几乎所有的文件系统都会把文件分割成固定大小的块来存储，通常一个块的大小为4K。如果磁盘中的扇区为512byte,而文件系统的块大小为4K,那么文件系统的存储单元就为8个扇区。这也是前面提到的一个问题，文件大小和占用空间之间有什么区别?文件大小是文件实际的大小，而占用空间则是因为即使它的实际大小没有达到那么大,但是这部分空间实际也被占用，其他文件数据无法使用这部分的空间。所以我们 写入1byte的数据到文本中,但是它占用的空间也会是4K。

这里要注意在Windows下的NTFS文件系统中，如果一开始文件数据小于 1K,那么则不会分配磁盘块来存储，而是存在一个文件表中。但是一旦文件数据大于1K,那么不管以后文件的大小，都会分配以4K为单位的磁盘空间来存储。

与内存管理一样,为了方便对磁盘的管理,文件的逻辑地址也被分为一个个的文件块。于是文件的逻辑地址就是(逻辑块号，块内地址)。用户通过逻辑地址来操作文件,操作系统负责完成逻辑地址与物理地址的映射。

不同的文件系统为文件分配磁盘空间会有不同的方式，这些方式各自都有优缺点。

连续分配要求每个文件在磁盘上有一组连续的块，该分配方式较为简单。

通过上图可以看到，文件的逻辑块号的顺序是与物理块号相同的,这样就可以实现随机存取了，只要知道了第一个逻辑块的物理地址, 那么就可以快速访问到其他逻辑块的物理地址。那么操作系统如何完成逻辑块与物理块之间的映射呢?实际上,文件都是存放在目录下的，而目录是一种有结构文件, 所以在文件目录的记录中会存放目录下所有文件的信息，每一个文件或者目录都是一个记录。 而这些信息就包括文件的起始块号和占有块号的数量。

那么操作系统如何完成逻辑块与物理块之间的映射呢? (逻辑块号, 块内地址) -> (物理块号, 块内地址)，只需要知道逻辑块号对应的物理块号即可,块内地址不变。

用户访问一个文件的内容,操作系统通过文件的标识符找到目录项FCB, 物理块号=起始块号+逻辑块号。 当然，还需要检查逻辑块号是否合法,是否超过长度等。因为可以根据逻辑块号直接算出物理块号，所以连续分配支持 顺序访问和随机访问 。

因为读/写文件是需要移动磁头的，如果访问两个相隔很远的磁盘块,移动磁头的时间就会变长。使用连续分配来作为文件的分配方式，会使文件的磁盘块相邻，所以文件的读/写速度最快。

连续空间存放的方式虽然读写效率高，但是有 磁盘空间碎片 和 文件长度不易扩展 的缺陷。

如下图，如果文件B被删除，磁盘上就留下一块空缺，这时，如果新来的文件小于其中的一个空缺，我们就可以将其放在相应空缺里。但如果该文件的大小大于所

有的空缺，但却小于空缺大小之和，则虽然磁盘上有足够的空缺，但该文件还是不能存放。当然了，我们可以通过将现有文件进行挪动来腾出空间以容纳新的文件,但是这个在磁盘挪动文件是非常耗时，所以这种方式不太现实。

另外一个缺陷是文件长度扩展不方便，例如上图中的文件A要想扩大一下，需要更多的磁盘空间,唯一的办法就只能是挪动的方式，前面也说了，这种方式效率是非常低的。

那么有没有更好的方式来解决上面的问题呢?答案当然有，既然连续空间存放的方式不太行，那么我们就改变存放的方式，使用非连续空间存放方式来解决这些缺陷。

非连续空间存放方式分为 链表方式 和 索引方式 。

链式分配采取离散分配的方式，可以为文件分配离散的磁盘块。它有两种分配方式:显示链接和隐式链接。

隐式链接是只目录项中只会记录文件所占磁盘块中的第一块的地址和最后一块磁盘块的地址, 然后通过在每一个磁盘块中存放一个指向下一 磁盘块的指针， 从而可以根据指针找到下一块磁盘块。如果需要分配新的磁盘块,则使用最后一块磁盘块中的指针指向新的磁盘块,然后修改新的磁盘块为最后的磁盘块。

我们来思考一个问题, 采用隐式链接如何将实现逻辑块号转换为物理块号呢?

用户给出需要访问的逻辑块号i,操作系统需要找到所需访问文件的目录项FCB.从目录项中可以知道文件的起始块号，然后将逻辑块号0的数据读入内存,由此知道1号逻辑块的物理块号，然后再读入1号逻辑块的数据进内存，此次类推，最终可以找到用户所需访问的逻辑块号i。访问逻辑块号i,总共需要i+ 1次磁盘1/0操作。

得出结论: 隐式链接分配只能顺序访问，不支持随机访问，查找效率低 。

我们来思考另外一个问题，采用隐式链接是否方便文件拓展?

我们知道目录项中存有结束块号的物理地址，所以我们如果要拓展文件，只需要将新分配的磁盘块挂载到结束块号的后面即可，修改结束块号的指针指向新分配的磁盘块，然后修改目录项。

得出结论: 隐式链接分配很方便文件拓展。所有空闲磁盘块都可以被利用到，无碎片问题，存储利用率高。

显示链接是把用于链接各个物理块的指针显式地存放在一张表中，该表称为文件分配表(FAT, File Allocation Table)。

由于查找记录的过程是在内存中进行的,因而不仅显着地 提高了检索速度 ，而且 大大减少了访问磁盘的次数 。但也正是整个表都存放在内存中的关系，它的主要的缺点是 不适 用于大磁盘 。

比如，对于200GB的磁盘和1KB大小的块，这张表需要有2亿项，每一项对应于这2亿个磁盘块中的一个块,每项如果需要4个字节，那这张表要占用800MB内存,很显然FAT方案对于大磁盘而言不太合适。

一直都在，加油！（*゜Д゜）σ凸←自爆按钮

链表的方式解决了连续分配的磁盘碎片和文件动态打展的问题，但是不能有效支持直接访问(FAT除外) ,索引的方式可以解决这个问题。

索引的实现是为每个文件创建一个 索引数据块 ，里面存放的 是指向文件数据块的指针列表 ,说白了就像书的目录一样,要找哪个章节的内容,看目录查就可以。

另外， 文件头需要包含指向索引数据块的指针 ,这样就可以通过文件头知道索引数据块的位置，再通过索弓|数据块里的索引信息找到对应的数据块。

创建文件时，索引块的所有指针都设为空。当首次写入第i块时，先从空闲空间中取得一个块， 再将其地址写到索引块的第i个条目。

索引的方式优点在于:

●文件的创建、增大、缩小很方便;

●不会有碎片的问题;

●支持顺序读写和随机读写;

由于索引数据也是存放在磁盘块的，如果文件很小，明明只需一块就可以存放的下，但还是需要额外分配一块来存放索引数据，所以缺陷之一就是存储索引带来的开销。

如果文件很大，大到一个索引数据块放不下索引信息，这时又要如何处理大文件的存放呢?我们可以通过组合的方式，来处理大文件的存储。

先来看看 链表+索引 的组合，这种组合称为 链式索引块 ，它的实现方式是在 索引数据块留出一个存放下一个索引数据块的指针 ，于是当一个索引数据块的索引信息用完了，就可以通过指针的方式，找到下一个索引数据块的信息。那这种方式也会出现前面提到的链表方式的问题，万一某个指针损坏了，后面的数据也就会无法读取了。

还有另外一种组合方式是 索引+索引 的方式，这种组合称为多级索引块，实现方式是通过一个索引块来存放多个索引数据块,一层套一层索引， 像极了俄罗斯套娃是吧๑乛◡乛๑ 

前面说到的文件的存储是针对已经被占用的数据块组织和管理，接下来的问题是，如果我要保存一个数据块, 我应该放在硬盘上的哪个位置呢?难道需要将所有的块扫描一遍，找个空的地方随便放吗?

那这种方式效率就太低了，所以针对磁盘的空闲空间也是要引入管理的机制，接下来介绍几种常见的方法:

●空闲表法

●空闲链表法

●位图法

空闲表法

空闲表法就是为所有空闲空间建立一张表，表内容包括空闲区的第一个块号和该空闲区的块个数，注意，这个方式是连续分配的。如下图:

当请求分配磁盘空间时，系统依次扫描空闲表里的内容，直到找到一个合适的空闲区域为止。当用户撤销一个文件时，系统回收文件空间。这时，也需顺序扫描空闲表,寻找一个空闲表条目并将释放空间的第一个物理块号及它占用的块数填到这个条目中。

这种方法仅当有少量的空闲区时才有较好的效果。因为，如果存储空间中有着大量的小的空闲区,则空闲表变得很大,这样查询效率会很低。另外，这种分配技术适用于建立连续文件。

空闲链表法

我们也可以使用链表的方式来管理空闲空间，每一个空闲块里有一个指针指向下一个空闲块，这样也能很方便的找到空闲块并管理起来。如下图：

当创建文件需要一块或几块时，就从链头上依次取下一块或几块。反之，当回收空间时，把这些空闲块依次接到链头上。

这种技术只要在主存中保存一个指针, 令它指向第一个空闲块。其特点是简单,但不能随机访问，工作效率低，因为每当在链上增加或移动空闲块时需要做很多1/0操作,同时数据块的指针消耗了一定的存储空间。

空闲表法和空闲链表法都不适合用于大型文件系统，因为这会使空闲表或空闲链表太大。

位图法

位图是利用二进制的一位来表示磁盘中一个盘块的使用情况，磁盘上所有的盘块都有一个二进制位与之对应。

当值为0时，表示对应的盘块空闲，值为1时，表示对应的盘块已分配。它形式如下:

在Linux文件系统就采用了位图的方式来管理空闲空间,不仅用于数据空闲块的管理,还用于inode空闲块的管理，因为inode也是存储在磁盘的，自然也要有对其管理。

前面提到Linux是用位图的方式管理空闲空间，用户在创建一个新文件时， Linux 内核会通过inode的位图找到空闲可用的inode,并进行分配。要存储数据时，会通过块的位图找到空闲的块，并分配，但仔细计算一下还是有问题的。

数据块的位图是放在磁盘块里的，假设是放在一个块里,一个块4K,每位表示一个数据块,共可以表示4 * 1024 * 8 = 2^15个空闲块,由于1个数据块是4K大小，那么最大可以表示的空间为2^15 * 4 * 1024 = 2^27个byte,也就是128M。

也就是说按照上面的结构，如果采用（一个块的位图+ 一系列的块），外加一（个块的inode的位图+一系列的inode）的结构能表示的最大空间也就128M,

这太少了，现在很多文件都比这个大。

在Linux文件系统，把这个结构称为一个 块组 ，那么有N多的块组,就能够表示N大的文件。

最终,整个文件系统格式就是下面这个样子。

最前面的第一个块是引导块,在系统启动时用于启用引导，接着后面就是一个一个连续的块组了,块组的内容如下:

● 超级块 ,包含的是文件系统的重要信息，比如inode总个数、块总个数、每个块组的inode个数、每个块组的块个数等等。

● 块组描述符 ,包含文件系统中各个块组的状态,比如块组中空闲块和inode的数目等，每个块组都包含了文件系统中“所有块组的组描述符信息”。

● 数据位图和inode位图 ，用于表示对应的数据块或inode是空闲的，还是被使用中。

● inode 列表 ，包含了块组中所有的inode, inode 用于保存文件系统中与各个文件和目录相关的所有元数据。

● 数据块 ，包含文件的有用数据。

你可以会发现每个块组里有很多重复的信息，比如 超级块和块组描述符表，这两个都是全局信息，而且非常的重要 ，这么做是有两个原因:

●如果系统崩溃破坏了超级块或块组描述符,有关文件系统结构和内容的所有信息都会丢失。如果有冗余的副本,该信息是可能恢复的。

●通过使文件和管理数据尽可能接近，减少了磁头寻道和旋转,这可以提高文件系统的性能。

不过，Ext2 的后续版本采用了稀疏技术。该做法是，超级块和块组描述符表不再存储到文件系统的每个块组中,而是只写入到块组0、块组1和其他ID可以表示为3、5、7的幂的块组中。

在前面，我们知道了一个普通文件是如何存储的，但还有一个特殊的文件,经常用到的目录，它是如何保存的呢?

基于Linux 一切切皆文件的设计思想，目录其实也是个文件,你甚至可以通过vim打开它，它也有inode, inode 里面也是指向一些块。

和普通文件不同的是， 普通文件的块里面保存的是文件数据，而目录文件的块里面保存的是目录里面一项一项的文件信息 。

在目录文件的块中，最简单的保存格式就是 列表 ，就是一项一项地将目录下的文件信息(如文件名、文件inode.文件类型等)列在表里。

列表中每一项就代表该目录下的文件的文件名和对应的inode,通过这个inode,就可以找到真正的文件。

通常，第一项是“则”，表示当前目录,第二项是.，表示上一级目录, 接下来就是一项一项的文件名和inode。

如果一个目录有超级多的文件,我们要想在这个目录下找文件,按照列表一项一项的找,效率就不高了。

于是，保存目录的格式改成 哈希表 ，对文件名进行哈希计算,把哈希值保存起来,如果我们要查找一个目录下面的文件名，可以通过名称取哈希。如果哈希能够匹配上,就说明这个文件的信息在相应的块里面。

Linux系统的ext文件系统就是采用了哈希表，来保存目录的内容,这种方法的优点是查找非常迅速，插入和删除也较简单,不过需要一些预备措施来避免哈希冲突。

目录查询是通过在磁盘上反复搜索完成，需要不断地进行/0操作,开销较大。所以,为了减少/0操作,把当前使用的文件目录缓存在内存，以后要使用该文件时只要在内存中操作，从而降低了磁盘操作次数,提高了文件系统的访问速度。

感谢您的阅读，希望您能摄取到知识！加油！冲冲冲！（发现光，追随光，成为光，散发光！）我是程序员耶耶！有缘再见。<－biubiu－⊂(`ω´∩)

㈡ linux 文件系统 是什么意思

文件系统是操作系统用于明确存储设备（常见的是磁盘，也有基于NANDFlash的固态硬盘）或分区上的文件的方法和数据结构；
即在存储设备上组织文件的方法。
操作系统中负责管理和存储文件信息的软件机构称为文件管理系统，简称文件系统。
文件系统由三部分组成：文件系统的接口，对对象操纵和管理的软件集合，对象及属性。
从系统角度来看，文件系统是对文件存储设备的空间进行组织和分配，负责文件存储并对存入的文件进行保护和检索的系统。

㈢ ext2exploder镐庝箞淇鏀筶inux镄勭郴缁熸枃浠

1.ext2鏂囦欢绯荤粺鏁翠綋甯冨眬
涓涓纾佺洏鍙浠ュ垝鍒嗘垚澶氢釜鍒嗗尯锛屾疮涓鍒嗗尯蹇呴’鍏堢敤镙煎纺鍖栧伐鍏凤纸渚嫔傛煇绉峬kfs锻戒护锛夋牸寮忓寲鎴愭煇绉嶆牸寮忕殑鏂囦欢绯荤粺锛岀劧钖庢墠鑳藉瓨鍌ㄦ枃浠讹纴镙煎纺鍖栫殑杩囩▼浼氩湪纾佺洏涓婂啓涓浜涚＄悊瀛桦偍甯冨眬镄勪俊鎭銆备笅锲炬槸涓涓纾佺洏鍒嗗尯镙煎纺鍖栨垚ext2鏂囦欢绯荤粺钖庣殑瀛桦偍甯冨眬銆

鏂囦欢绯荤粺涓瀛桦偍镄勬渶灏忓崟浣嶆槸鍧楋纸Block锛夛纴涓涓鍧楃┒绔熷氩ぇ鏄鍦ㄦ牸寮忓寲镞剁‘瀹氱殑锛屼緥濡俶ke2fs镄-b阃夐”鍙浠ヨ惧畾鍧楀ぇ灏忎负1024銆2048鎴4096瀛楄妭锛岃繖浜 blocks 琚镵氩湪涓璧峰垎鎴愬嚑涓澶х殑 block group銆傛疮涓 block group 涓链夊氩皯涓 block 鏄锲哄畾镄勚傝屼笂锲句腑钖锷ㄥ潡锛圔oot Block锛夌殑澶у皬鏄纭瀹氱殑锛屽氨鏄1KB锛屽惎锷ㄥ潡鏄鐢盘C镙囧嗳瑙勫畾镄勶纴鐢ㄦ潵瀛桦偍纾佺洏鍒嗗尯淇℃伅鍜屽惎锷ㄤ俊鎭锛屼换浣曟枃浠剁郴缁熼兘涓嶈兘浣跨敤钖锷ㄥ潡銆傚惎锷ㄥ潡涔嫔悗镓嶆槸ext2鏂囦欢绯荤粺镄勫紑濮嬶纴ext2鏂囦欢绯荤粺灏嗘暣涓鍒嗗尯鍒掓垚鑻ュ共涓钖屾牱澶у皬镄勫潡缁勶纸Block Group锛夛纴姣忎釜鍧楃粍閮界敱浠ヤ笅閮ㄥ垎缁勬垚

1).瓒呯骇鍧楋纸Super Block锛
鎻忚堪鏁翠釜鍒嗗尯镄勬枃浠剁郴缁熶俊鎭锛屼緥濡傚潡澶у皬銆佹枃浠剁郴缁熺増链鍙枫佷笂娆mount镄勬椂闂寸瓑绛夈傝秴绾у潡鍦ㄦ疮涓鍧楃粍镄勫紑澶撮兘链変竴浠芥嫹璐濄

2).鍧楃粍鎻忚堪绗﹁〃锛圙DT锛孏roup Descriptor Table)
鐢卞緢澶氩潡缁勬弿杩扮︾粍鎴愶纴鏁翠釜鍒嗗尯鍒嗘垚澶氩皯涓鍧楃粍灏卞瑰簲链夊氩皯涓鍧楃粍鎻忚堪绗︺傛疮涓鍧楃粍鎻忚堪绗︼纸Group Descriptor锛夊瓨鍌ㄤ竴涓鍧楃粍镄勬弿杩颁俊鎭锛屼緥濡傚湪杩欎釜鍧楃粍涓浠庡摢閲屽紑濮嬫槸inode琛锛屼粠鍝閲屽紑濮嬫槸鏁版嵁鍧楋纴绌洪棽镄刬node鍜屾暟鎹鍧楄缮链夊氩皯涓绛夌瓑銆傚拰瓒呯骇鍧楃被浼硷纴鍧楃粍鎻忚堪绗﹁〃鍦ㄦ疮涓鍧楃粍镄勫紑澶翠篃閮芥湁涓浠芥嫹璐濓纴杩欎簺淇℃伅鏄闱炲父閲嶈佺殑锛屼竴镞﹁秴绾у潡镒忓栨崯鍧忓氨浼氢涪澶辨暣涓鍒嗗尯镄勬暟鎹锛屼竴镞﹀潡缁勬弿杩扮︽剰澶栨崯鍧忓氨浼氢涪澶辨暣涓鍧楃粍镄勬暟鎹锛屽洜姝ゅ畠浠閮芥湁澶氢唤𨰾疯礉銆傞氩父鍐呮牳鍙鐢ㄥ埌绗0涓鍧楃粍涓镄勬嫹璐濓纴褰撴墽琛宔2fsck妫镆ユ枃浠剁郴缁熶竴镊存ф椂锛岀0涓鍧楃粍涓镄勮秴绾у潡鍜屽潡缁勬弿杩扮﹁〃灏变细𨰾疯礉鍒板叾瀹冨潡缁勶纴杩欐牱褰撶0涓鍧楃粍镄勫紑澶存剰澶栨崯鍧忔椂灏卞彲浠ョ敤鍏跺畠𨰾疯礉𨱒ユ仮澶嶏纴浠庤屽噺灏戞崯澶便

3).鍧椾綅锲撅纸Block Bitmap锛
涓涓鍧楃粍涓镄勫潡鏄杩欐牱鍒╃敤镄勶细鏁版嵁鍧楀瓨鍌ㄦ墍链夋枃浠剁殑鏁版嵁锛屾瘆濡傛煇涓鍒嗗尯镄勫潡澶у皬鏄1024瀛楄妭锛屾煇涓鏂囦欢鏄2049瀛楄妭锛岄偅涔埚氨闇瑕佷笁涓鏁版嵁鍧楁潵瀛桡纴鍗充娇绗涓変釜鍧楀彧瀛树简涓涓瀛楄妭涔熼渶瑕佸崰鐢ㄤ竴涓鏁村潡锛涜秴绾у潡銆佸潡缁勬弿杩扮﹁〃銆佸潡浣嶅浘銆乮node浣嶅浘銆乮node琛ㄨ繖鍑犻儴鍒嗗瓨鍌ㄨュ潡缁勭殑鎻忚堪淇℃伅銆傞偅涔埚备綍鐭ラ亾鍝浜涘潡宸茬粡鐢ㄦ潵瀛桦偍鏂囦欢鏁版嵁鎴栧叾瀹冩弿杩颁俊鎭锛屽摢浜涘潡浠岖劧绌洪棽鍙鐢ㄥ憿锛熷潡浣嶅浘灏辨槸鐢ㄦ潵鎻忚堪鏁翠釜鍧楃粍涓鍝浜涘潡宸茬敤鍝浜涘潡绌洪棽镄勶纴瀹冩湰韬鍗犱竴涓鍧楋纴鍏朵腑镄勬疮涓狰it浠ｈ〃链鍧楃粍涓镄勪竴涓鍧楋纴杩欎釜bit涓1琛ㄧず璇ュ潡宸茬敤锛岃繖涓狰it涓0琛ㄧず璇ュ潡绌洪棽鍙鐢ㄣ
涓轰粈涔堢敤df锻戒护缁熻℃暣涓纾佺洏镄勫凡鐢ㄧ┖闂撮潪甯稿揩锻锛熷洜涓哄彧闇瑕佹煡鐪嬫疮涓鍧楃粍镄勫潡浣嶅浘鍗冲彲锛岃屼笉闇瑕佹悳阆嶆暣涓鍒嗗尯銆傜浉鍙嶏纴鐢╠u锻戒护镆ョ湅涓涓杈冨ぇ鐩褰旷殑宸茬敤绌洪棿灏遍潪甯告参锛屽洜涓轰笉鍙阆垮厤鍦拌佹悳阆嶆暣涓鐩褰旷殑镓链夋枃浠躲
涓庢ょ浉镵旂郴镄勫彟涓涓闂棰樻槸锛氩湪镙煎纺鍖栦竴涓鍒嗗尯镞剁┒绔熶细鍒掑嚭澶氩皯涓鍧楃粍锻锛熶富瑕佺殑闄愬埗鍦ㄤ簬鍧椾綅锲炬湰韬蹇呴’鍙鍗犱竴涓鍧椼傜敤mke2fs镙煎纺鍖栨椂榛樿ゅ潡澶у皬鏄1024瀛楄妭锛屽彲浠ョ敤-b鍙傛暟鎸囧畾鍧楀ぇ灏忥纴鐜板湪璁惧潡澶у皬鎸囧畾涓篵瀛楄妭锛岄偅涔堜竴涓鍧楀彲浠ユ湁8b涓狰it锛岃繖镙峰ぇ灏忕殑涓涓鍧椾綅锲惧氨鍙浠ヨ〃绀8b涓鍧楃殑鍗犵敤𨱍呭喌锛屽洜姝や竴涓鍧楃粍链澶氩彲浠ユ湁8b涓鍧楋纴濡傛灉鏁翠釜鍒嗗尯链塻涓鍧楋纴闾ｄ箞灏卞彲浠ユ湁s/(8b)涓鍧楃粍銆傛牸寮忓寲镞跺彲浠ョ敤-g鍙傛暟鎸囧畾涓涓鍧楃粍链夊氩皯涓鍧楋纴浣嗘槸阃氩父涓嶉渶瑕佹坠锷ㄦ寚瀹氾纴mke2fs宸ュ叿浼氲＄畻鍑烘渶浼樼殑鏁板笺

4).inode浣嶅浘锛坕node Bitmap锛
鍜屽潡浣嶅浘绫讳技锛屾湰韬鍗犱竴涓鍧楋纴鍏朵腑姣忎釜bit琛ㄧず涓涓猧node鏄钖︾┖闂插彲鐢

5).inode琛锛坕node Table锛
鎴戜滑鐭ラ亾锛屼竴涓鏂囦欢闄や简鏁版嵁闇瑕佸瓨鍌ㄤ箣澶栵纴涓浜涙弿杩颁俊鎭涔熼渶瑕佸瓨鍌锛屼緥濡傛枃浠剁被鍨嬶纸甯歌勚佺洰褰曘佺﹀彿阈炬帴绛夛级锛屾潈闄愶纴鏂囦欢澶у皬锛屽垱寤/淇鏀/璁块梾镞堕棿绛夛纴涔熷氨鏄痩s -l锻戒护鐪嫔埌镄勯偅浜涗俊鎭锛岃繖浜涗俊鎭瀛桦湪inode涓钥屼笉鏄鏁版嵁鍧椾腑銆傛疮涓鏂囦欢閮芥湁涓涓猧node锛屼竴涓鍧楃粍涓镄勬墍链塱node缁勬垚浜唅node琛ㄣ
inode琛ㄥ崰澶氩皯涓鍧楀湪镙煎纺鍖栨椂灏辫佸喅瀹氩苟鍐椤叆鍧楃粍鎻忚堪绗︿腑锛宫ke2fs镙煎纺鍖栧伐鍏风殑榛樿ょ瓥鐣ユ槸涓涓鍧楃粍链夊氩皯涓8KB灏卞垎閰嶅氩皯涓猧node銆傜敱浜庢暟鎹鍧楀崰浜嗘暣涓鍧楃粍镄勭粷澶ч儴鍒嗭纴涔熷彲浠ヨ繎浼艰や负鏁版嵁鍧楁湁澶氩皯涓8KB灏卞垎閰嶅氩皯涓猧node锛屾崲鍙ヨ瘽璇达纴濡傛灉骞冲潎姣忎釜鏂囦欢镄勫ぇ灏忔槸8KB锛屽綋鍒嗗尯瀛樻弧镄勬椂鍊檌node琛ㄤ细寰楀埌姣旇缉鍏呭垎镄勫埄鐢锛屾暟鎹鍧椾篃涓嶆氮璐广傚傛灉杩欎釜鍒嗗尯瀛樼殑閮芥槸寰埚ぇ镄勬枃浠讹纸姣斿傜数褰憋级锛屽垯鏁版嵁鍧楃敤瀹岀殑镞跺檌node浼氭湁涓浜涙氮璐癸纴濡傛灉杩欎釜鍒嗗尯瀛樼殑閮芥槸寰埚皬镄勬枃浠讹纸姣斿傛簮浠ｇ爜锛夛纴鍒欐湁鍙鑳芥暟鎹鍧楄缮娌＄敤瀹宨node灏卞凡缁忕敤瀹屼简锛屾暟鎹鍧楀彲鑳芥湁寰埚ぇ镄勬氮璐广傚傛灉鐢ㄦ埛鍦ㄦ牸寮忓寲镞惰兘澶熷硅繖涓鍒嗗尯浠ュ悗瑕佸瓨鍌ㄧ殑鏂囦欢澶у皬锅氢竴涓棰勬祴锛屼篃鍙浠ョ敤mke2fs镄-i鍙傛暟镓嫔姩鎸囧畾姣忓氩皯涓瀛楄妭鍒嗛厤涓涓猧node銆

6).鏁版嵁鍧楋纸Data Block锛
镙规嵁涓嶅悓镄勬枃浠剁被鍨嬫湁浠ヤ笅鍑犵嶆儏鍐
瀵逛簬甯歌勬枃浠讹纴鏂囦欢镄勬暟鎹瀛桦偍鍦ㄦ暟鎹鍧椾腑銆
瀵逛簬鐩褰曪纴璇ョ洰褰曚笅镄勬墍链夋枃浠跺悕鍜岀洰褰曞悕瀛桦偍鍦ㄦ暟鎹鍧椾腑锛屾敞镒忔枃浠跺悕淇濆瓨鍦ㄥ畠镓鍦ㄧ洰褰旷殑鏁版嵁鍧椾腑锛岄櫎鏂囦欢钖崭箣澶栵纴ls -l锻戒护鐪嫔埌镄勫叾瀹冧俊鎭閮戒缭瀛桦湪璇ユ枃浠剁殑inode涓銆傛敞镒忚繖涓姒傚康锛氱洰褰曚篃鏄涓绉嶆枃浠讹纴鏄涓绉岖壒娈婄被鍨嬬殑鏂囦欢銆
瀵逛簬绗﹀彿阈炬帴锛屽傛灉鐩镙囱矾寰勫悕杈幂煭鍒欑洿鎺ヤ缭瀛桦湪inode涓浠ヤ究镟村揩鍦版煡镓撅纴濡傛灉鐩镙囱矾寰勫悕杈冮暱鍒椤垎閰崭竴涓鏁版嵁鍧楁潵淇濆瓨銆
璁惧囨枃浠躲丗IFO鍜宻ocket绛夌壒娈婃枃浠舵病链夋暟鎹鍧楋纴璁惧囨枃浠剁殑涓昏惧囧彿鍜屾¤惧囧彿淇濆瓨鍦╥node涓銆

2.鏁版嵁鍧楀诲潃
濡傛灉涓涓鏂囦欢链夊氢釜鏁版嵁鍧楋纴杩欎簺鏁版嵁鍧楀緢鍙鑳戒笉鏄杩炵画瀛樻斁镄勶纴搴旇ュ备綍瀵诲潃鍒版疮涓鍧楀憿锛熷疄闄呬笂锛屾牴鐩褰旷殑鏁版嵁鍧楁槸阃氲繃鍏籼node涓镄勭储寮曢”Blocks[0]镓惧埌镄勶纴浜嫔疄涓婏纴杩欐牱镄勭储寮曢”涓鍏辨湁15涓锛屼粠Blocks[0]鍒痫locks[14]锛屾疮涓绱㈠紩椤瑰崰4瀛楄妭銆傚墠12涓绱㈠紩椤归兘琛ㄧず鍧楃紪鍙凤纴渚嫔备笂闱㈢殑渚嫔瓙涓𪻐locks[0]瀛楁典缭瀛樼潃24锛屽氨琛ㄧず绗24涓鍧楁槸璇ユ枃浠剁殑鏁版嵁鍧楋纴濡傛灉鍧楀ぇ灏忔槸1KB锛岃繖镙峰彲浠ヨ〃绀轰粠0瀛楄妭鍒12KB镄勬枃浠躲傚傛灉鍓╀笅镄勪笁涓绱㈠紩椤笲locks[12]鍒痫locks[14]涔熸槸杩欎箞鐢ㄧ殑锛屽氨鍙鑳借〃绀烘渶澶15KB镄勬枃浠朵简锛岃繖鏄杩滆繙涓嶅熺殑锛屼簨瀹炰笂锛屽墿涓嬬殑涓変釜绱㈠紩椤归兘鏄闂存帴绱㈠紩銆
绱㈠紩椤笲locks[12]镓鎸囧悜镄勫潡骞堕潪鏁版嵁鍧楋纴钥屾槸绉颁负闂存帴瀵诲潃鍧楋纸Indirect Block锛夛纴鍏朵腑瀛樻斁镄勯兘鏄绫讳技Blocks[0]杩欑岖储寮曢”锛屽啀鐢辩储寮曢”鎸囧悜鏁版嵁鍧椼傝惧潡澶у皬鏄痓锛岄偅涔堜竴涓闂存帴瀵诲潃鍧椾腑鍙浠ュ瓨鏀绰/4涓绱㈠紩椤癸纴鎸囧悜b/4涓鏁版嵁鍧椼傛墍浠ュ傛灉鎶夿locks[0]鍒痫locks[12]閮界敤涓婏纴链澶氩彲浠ヨ〃绀篵/4+12涓鏁版嵁鍧楋纴瀵逛簬鍧楀ぇ灏忔槸1K镄勬儏鍐碉纴链澶у彲琛ㄧず268K镄勬枃浠躲傚备笅锲炬墍绀猴纴娉ㄦ剰鏂囦欢镄勬暟鎹鍧楃紪鍙锋槸浠0寮濮嬬殑锛孊locks[0]鎸囧悜绗0涓鏁版嵁鍧楋纴Blocks[11]鎸囧悜绗11涓鏁版嵁鍧楋纴Blocks[12]镓鎸囧悜镄勯棿鎺ュ诲潃鍧楃殑绗涓涓绱㈠紩椤规寚钖戠12涓鏁版嵁鍧楋纴渚濇ょ被鎺ㄣ

浠庝笂锲惧彲浠ョ湅鍑猴纴绱㈠紩椤笲locks[13]鎸囧悜涓ょ骇镄勯棿鎺ュ诲潃鍧楋纴链澶氩彲琛ㄧず(b/4)2+b/4+12涓鏁版嵁鍧楋纴瀵逛簬1K镄勫潡澶у皬链澶у彲琛ㄧず64.26MB镄勬枃浠躲傜储寮曢”Blocks[14]鎸囧悜涓夌骇镄勯棿鎺ュ诲潃鍧楋纴链澶氩彲琛ㄧず(b/4)3+(b/4)2+b/4+12涓鏁版嵁鍧楋纴瀵逛簬1K镄勫潡澶у皬链澶у彲琛ㄧず16.06GB镄勬枃浠躲
鍙瑙侊纴杩欑嶅诲潃鏂瑰纺瀵逛簬璁块梾涓嶈秴杩12涓鏁版嵁鍧楃殑灏忔枃浠舵槸闱炲父蹇镄勶纴璁块梾鏂囦欢涓镄勪换镒忔暟鎹鍙闇瑕佷袱娆¤荤洏镎崭綔锛屼竴娆¤籭node锛堜篃灏辨槸璇荤储寮曢”锛変竴娆¤绘暟鎹鍧椼傝岃块梾澶ф枃浠朵腑镄勬暟鎹鍒欓渶瑕佹渶澶氢簲娆¤荤洏镎崭綔锛歩node銆佷竴绾ч棿鎺ュ诲潃鍧椼佷簩绾ч棿鎺ュ诲潃鍧椼佷笁绾ч棿鎺ュ诲潃鍧椼佹暟鎹鍧椼傚疄闄呬笂锛岀佺洏涓镄刬node鍜屾暟鎹鍧楀线寰宸茬粡琚鍐呮牳缂揿瓨浜嗭纴璇诲ぇ鏂囦欢镄勬晥鐜囦篃涓崭细澶浣庛

3.鏂囦欢鍜岀洰褰曟搷浣灭殑绯荤粺鍑芥暟(杩欓噷闱㈢殑"(n)"搴旇ヨ〃绀哄弬鏁扮殑涓鏁)
1).stat(2)鍑芥暟璇诲彇鏂囦欢镄刬node锛岀劧钖庢妸inode涓镄勫悇绉嶆枃浠跺睘镐у～鍏ヤ竴涓狲truct stat缁撴瀯浣扑紶鍑虹粰璋幂敤钥呫俿tat(1)锻戒护鏄锘轰簬stat鍑芥暟瀹炵幇镄勚俿tat闇瑕佹牴鎹浼犲叆镄勬枃浠惰矾寰勬垒鍒癷node锛屽亣璁句竴涓璺寰勬槸/opt/file锛屽垯镆ユ垒镄勯‘搴忔槸锛
璇诲嚭inode琛ㄤ腑绗2椤癸纴涔熷氨鏄镙圭洰褰旷殑inode锛屼粠涓镓惧嚭镙圭洰褰曟暟鎹鍧楃殑浣岖疆
浠庢牴鐩褰旷殑鏁版嵁鍧椾腑镓惧嚭鏂囦欢钖崭负opt镄勮板綍锛屼粠璁板綍涓璇诲嚭瀹幂殑inode鍙
璇诲嚭opt鐩褰旷殑inode锛屼粠涓镓惧嚭瀹幂殑鏁版嵁鍧楃殑浣岖疆
浠巓pt鐩褰旷殑鏁版嵁鍧椾腑镓惧嚭鏂囦欢钖崭负file镄勮板綍锛屼粠璁板綍涓璇诲嚭瀹幂殑inode鍙
璇诲嚭file鏂囦欢镄刬node
杩樻湁鍙﹀栦袱涓绫讳技stat镄勫嚱鏁帮细fstat(2)鍑芥暟浼犲叆涓涓宸叉墦寮镄勬枃浠舵弿杩扮︼纴浼犲嚭inode淇℃伅锛宭stat(2)鍑芥暟涔熸槸浼犲叆璺寰勪紶鍑篿node淇℃伅锛屼絾鏄鍜宻tat鍑芥暟链変竴镣逛笉钖岋纴褰撴枃浠舵槸涓涓绗﹀彿阈炬帴镞讹纴stat(2)鍑芥暟浼犲嚭镄勬槸瀹冩墍鎸囧悜镄勭洰镙囨枃浠剁殑inode锛岃宭stat鍑芥暟浼犲嚭镄勫氨鏄绗﹀彿阈炬帴鏂囦欢链韬镄刬node銆

2).access(2)鍑芥暟妫镆ユ墽琛屽綋鍓嶈繘绋嬬殑鐢ㄦ埛鏄钖︽湁𨱒冮檺璁块梾镆愪釜鏂囦欢锛屼紶鍏ユ枃浠惰矾寰勫拰瑕佹墽琛岀殑璁块梾镎崭綔锛堣/鍐/镓ц岋级锛宎ccess鍑芥暟鍙栧嚭鏂囦欢inode涓镄剆t_mode瀛楁碉纴姣旇缉涓涓嬭块梾𨱒冮檺锛岀劧钖庤繑锲0琛ㄧず鍏佽歌块梾锛岃繑锲-1琛ㄧず阌栾鎴栦笉鍏佽歌块梾銆

3).chmod(2)鍜宖chmod(2)鍑芥暟鏀瑰彉鏂囦欢镄勮块梾𨱒冮檺锛屼篃灏辨槸淇鏀筰node涓镄剆t_mode瀛楁点傝繖涓や釜鍑芥暟镄勫尯鍒绫讳技浜巗tat/fstat銆俢hmod(1)锻戒护鏄锘轰簬chmod鍑芥暟瀹炵幇镄勚

4).chown(2)/fchown(2)/lchown(2)鏀瑰彉鏂囦欢镄勬墍链夎呭拰缁勶纴涔熷氨鏄淇鏀筰node涓镄刄ser鍜孏roup瀛楁碉纴鍙链夎秴绾х敤鎴锋墠鑳芥ｇ‘璋幂敤杩椤嚑涓鍑芥暟锛岃繖鍑犱釜鍑芥暟涔嬮棿镄勫尯鍒绫讳技浜巗tat/fstat/lstat銆俢hown(1)锻戒护鏄锘轰簬chown鍑芥暟瀹炵幇镄勚

5).utime(2)鍑芥暟鏀瑰彉鏂囦欢镄勮块梾镞堕棿鍜屼慨鏀规椂闂达纴涔熷氨鏄淇鏀筰node涓镄刟time鍜宫time瀛楁点伥ouch(1)锻戒护鏄锘轰簬utime鍑芥暟瀹炵幇镄勚

6).truncate(2)鍜宖truncate(2)鍑芥暟鎶婃枃浠舵埅鏂鍒版煇涓闀垮害锛屽傛灉鏂扮殑闀垮害姣斿师𨱒ョ殑闀垮害鐭锛屽垯钖庨溃镄勬暟鎹琚鎴鎺変简锛屽傛灉鏂扮殑闀垮害姣斿师𨱒ョ殑闀垮害闀匡纴鍒椤悗闱㈠氩嚭𨱒ョ殑閮ㄥ垎鐢0濉鍏咃纴杩欓渶瑕佷慨鏀筰node涓镄凚locks绱㈠紩椤逛互鍙婂潡浣嶅浘涓鐩稿簲镄刡it銆傝繖涓や釜鍑芥暟镄勫尯鍒绫讳技浜巗tat/fstat銆

7).link(2)鍑芥暟鍒涘缓纭阈炬帴锛屽叾铡熺悊鏄鍦ㄧ洰褰旷殑鏁版嵁鍧椾腑娣诲姞涓𨱒℃柊璁板綍锛屽叾涓镄刬node鍙峰瓧娈靛拰铡熸枃浠剁浉钖屻俿ymlink(2)鍑芥暟鍒涘缓涓涓绗﹀彿阈炬帴锛岃繖闇瑕佸垱寤轰竴涓鏂扮殑inode锛屽叾涓璼t_mode瀛楁电殑鏂囦欢绫诲瀷鏄绗﹀彿阈炬帴锛屽师鏂囦欢镄勮矾寰勪缭瀛桦湪inode涓鎴栬呭垎閰崭竴涓鏁版嵁鍧楁潵淇濆瓨銆俵n(1)锻戒护鏄锘轰簬link鍜宻ymlink鍑芥暟瀹炵幇镄勚

8).unlink(2)鍑芥暟鍒犻櫎涓涓阈炬帴銆傚傛灉鏄绗﹀彿阈炬帴鍒欓喷鏀捐繖涓绗﹀彿阈炬帴镄刬node鍜屾暟鎹鍧楋纴娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲镄勪綅銆傚傛灉鏄纭阈炬帴鍒欎粠鐩褰旷殑鏁版嵁鍧椾腑娓呴櫎涓𨱒℃枃浠跺悕璁板綍锛屽傛灉褰揿墠鏂囦欢镄勭‖阈炬帴鏁板凡缁忔槸1浜呜缮瑕佸垹闄ゅ畠锛屽氨钖屾椂閲婃斁瀹幂殑inode鍜屾暟鎹鍧楋纴娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲镄勪綅锛岃繖镙峰氨鐪熺殑鍒犻櫎鏂囦欢浜嗐倁nlink(1)锻戒护鍜宺m(1)锻戒护鏄锘轰簬unlink鍑芥暟瀹炵幇镄勚

9).rename(2)鍑芥暟鏀瑰彉鏂囦欢钖嶏纴闇瑕佷慨鏀圭洰褰曟暟鎹鍧椾腑镄勬枃浠跺悕璁板綍锛屽傛灉铡熸枃浠跺悕鍜屾柊鏂囦欢钖崭笉鍦ㄤ竴涓鐩褰曚笅鍒欓渶瑕佷粠铡熺洰褰曟暟鎹鍧椾腑娓呴櫎涓𨱒¤板綍铹跺悗娣诲姞鍒版柊鐩褰旷殑鏁版嵁鍧椾腑銆俶v(1)锻戒护鏄锘轰簬rename鍑芥暟瀹炵幇镄勶纴锲犳ゅ湪钖屼竴鍒嗗尯镄勪笉钖岀洰褰曚腑绉诲姩鏂囦欢骞朵笉闇瑕佸嶅埗鍜屽垹闄ゆ枃浠剁殑inode鍜屾暟鎹鍧楋纴鍙闇瑕佷竴涓鏀瑰悕镎崭綔锛屽嵆浣胯佺Щ锷ㄦ暣涓鐩褰曪纴杩欎釜鐩褰曚笅链夊緢澶氩瓙鐩褰曞拰鏂囦欢涔熻侀殢镌涓璧风Щ锷锛岀Щ锷ㄦ搷浣滀篃鍙鏄瀵归《绾х洰褰旷殑鏀瑰悕镎崭綔锛屽緢蹇灏辫兘瀹屾垚銆备絾鏄锛屽傛灉鍦ㄤ笉钖岀殑鍒嗗尯涔嬮棿绉诲姩鏂囦欢灏卞繀椤诲嶅埗鍜屽垹闄inode鍜屾暟鎹鍧楋纴濡傛灉瑕佺Щ锷ㄦ暣涓鐩褰曪纴镓链夊瓙鐩褰曞拰鏂囦欢閮借佸嶅埗鍒犻櫎锛岃繖灏卞緢鎱浜嗐

10)readlink(2)鍑芥暟璇诲彇涓涓绗﹀彿阈炬帴镓鎸囧悜镄勭洰镙囱矾寰勶纴鍏跺师鐞嗘槸浠庣﹀彿阈炬帴镄刬node鎴栨暟鎹鍧椾腑璇诲嚭淇濆瓨镄勬暟鎹锛岃繖灏辨槸鐩镙囱矾寰勚

11).mkdir(2)鍑芥暟鍒涘缓鏂扮殑鐩褰曪纴瑕佸仛镄勬搷浣沧槸鍦ㄥ畠镄勭埗鐩褰曟暟鎹鍧椾腑娣诲姞涓𨱒¤板綍锛岀劧钖庡垎閰嶆柊镄刬node鍜屾暟鎹鍧楋纴inode镄剆t_mode瀛楁电殑鏂囦欢绫诲瀷鏄鐩褰曪纴鍦ㄦ暟鎹鍧椾腑濉涓や釜璁板綍锛屽垎鍒鏄.鍜..锛岀敱浜..琛ㄧず鐖剁洰褰曪纴锲犳ょ埗鐩褰旷殑纭阈炬帴鏁拌佸姞1銆俶kdir(1)锻戒护鏄锘轰簬mkdir鍑芥暟瀹炵幇镄勚

12).rmdir(2)鍑芥暟鍒犻櫎涓涓鐩褰曪纴杩欎釜鐩褰曞繀椤绘槸绌虹殑锛埚彧鍖呭惈.鍜..锛夋墠鑳藉垹闄わ纴瑕佸仛镄勬搷浣沧槸閲婃斁瀹幂殑inode鍜屾暟鎹鍧楋纴娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲镄勪綅锛屾竻闄ょ埗鐩褰曟暟鎹鍧椾腑镄勮板綍锛岀埗鐩褰旷殑纭阈炬帴鏁拌佸噺1銆俽mdir(1)锻戒护鏄锘轰簬rmdir鍑芥暟瀹炵幇镄勚

13).opendir(3)/readdir(3)/closedir(3)鐢ㄤ簬阆嶅巻鐩褰曟暟鎹鍧椾腑镄勮板綍銆俹pendir镓揿紑涓涓鐩褰曪纴杩斿洖涓涓狣IR *鎸囬拡浠ｈ〃杩欎釜鐩褰曪纴瀹冩槸涓涓绫讳技FILE *鎸囬拡镄勫彞镆勶纴closedir鐢ㄤ簬鍏抽棴杩欎釜鍙ユ焺锛屾妸DIR *鎸囬拡浼犵粰readdir璇诲彇鐩褰曟暟鎹鍧椾腑镄勮板綍锛屾疮娆¤繑锲炰竴涓鎸囧悜struct dirent镄勬寚阍堬纴鍙嶅嶈诲氨鍙浠ラ亶铡嗘墍链夎板綍锛屾墍链夎板綍阆嶅巻瀹屼箣钖巖eaddir杩斿洖NULL

㈣ Linux中的/目录在哪

1 通常一个 filesystem 的最顶层 inode 号码会由 2 号开始
2 每个文件系统里面有一张inode表 记录当前文件系统中的所有目录和文件,包 括 2 号的 / 也在里面

系统查找文件时,首先去找
/ 挂载点所在分区的那个文件系统中的inode 表中的2号结点.
比如：你分区为:
分区 挂载点
/dev/hda1 /boot ---这个挂boot目录
/dev/hda2 / ---这个挂/ 目录
/dev/hda3 /u ---这个挂/u目录

以上每一个分区都是一个独立的文件系统.它就会跑去 /dev/hda2这个分区
发现这个文件系统里面有以下内容:
inode table (inode表)
Superblock (超级区块)
Filesystem Description (文件系统描述说明)
block bitmap (区块对照表,就是描述哪个块空闲，哪个正在被用)
inode bitmap (inode 对照表,描述哪个inode空，哪个被用)
data block (数据块资料,存真正的文件数据)

又发现inode table 内容如下:

1 文件存取权限 创建时间 修改时间 ....对应的block
2 文件存取权限 创建时间 修改时间 ....对应的block
3 文件存取权限 创建时间 修改时间 ....对应的block
4 文件存取权限 创建时间 修改时间 ....对应的block

它就会很聪明地读 inode号为2 的 inode 这个就是 /
然后读它的 block 里面的资料,发现block 是一张表,资料如下:
inode号 文件名
4 etc
5 service
... .....

假如要读 etc 它就会读etc 对应的 inode 号 4
再拿4去上面那张表找4的数据块block...如此找下去.
当找到一个真正的文件时,发现是要的东西了.

这样说明白没有.