文件系统(六)：一文看懂linux ext4文件系统工作原理
liwen01 2024.06.09
前言
Linux系统中的ext2、ext3、ext4 文件系统，它们都有很强的向后和向前兼容性，可以在数据不丢失的情况下进行文件系统的升级。目前ext4是一个相对较成熟、稳定且高效的文件系统，适用于绝大部分规模和需求的Linux环境。
ext4它突出的特点有：数据分段管理、多块分配、延迟分配、持久预分配、日志校验、支持更大的文件系统和文件大小。
ext4文件系统的具体实现比较复杂，本文尝试用比较简单的方式用一篇文章的篇幅来简单地介绍一下它的工作原理。
(一)创建ext文件系统
为了分析ext4 文件系统的内部结构和原理，这里我们在Linux中创建一个ext4文件系统镜像，然后通过loop虚拟设备将ext4镜像文件挂载到某个目录上。具体实现步骤如下：
- 创建一个1GB的文件
dd if=/dev/zero of=./ext4_image.img bs=1M count=1024
- 将这个文件格式化成 ext4 文件系统格式
mkfs.ext4 ext4_image.img
- 通过Linux的loop虚拟设备将文件挂载到目录上
sudo mount -o loop ext4_image.img /home/biao/test/ext4/ext4_simulator
- dumpe2fs 查看文件系统基本信息
dumpe2fs ext4_image.img
输出内容信息(中间省略了部分内容):
dumpe2fs 1.44.1 (24-Mar-2018)
Filesystem volume name: <none>
Last mounted on: /home/biao/test/ext4/ext4_simulator
Filesystem UUID: 0169498e-f5f7-4fb8-9e9e-532088e41333
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 262144
Reserved block count: 13107
Free blocks: 247703
Free inodes: 65517
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 127
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Fri May 24 17:18:57 2024
Last mount time: Wed Jun 5 19:15:36 2024
Last write time: Wed Jun 5 19:15:36 2024
Mount count: 3
Maximum mount count: -1
Last checked: Fri May 24 17:18:57 2024
Check interval: 0 (<none>)
Lifetime writes: 6997 kB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 0faf0e8c-f385-4ecd-b3a4-db2a3329e121
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x32dc1b70
Journal features: journal_64bit journal_checksum_v3
Journal size: 32M
Journal length: 8192
Journal sequence: 0x00000017
Journal start: 1
Journal checksum type: crc32c
Journal checksum: 0xa3c1b983
Group 0: (Blocks 0-32767) csum 0xf19b [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-128
Block bitmap at 129 (+129), csum 0x8efc34cf
Inode bitmap at 137 (+137), csum 0x49f91ed6
Inode table at 145-656 (+145)
28517 free blocks, 8176 free inodes, 3 directories, 8176 unused inodes
Free blocks: 4251-32767
Free inodes: 17-8192
..........
..........
..........
Group 7: (Blocks 229376-262143) csum 0x7daa [INODE_UNINIT, ITABLE_ZEROED]
Backup superblock at 229376, Group descriptors at 229377-229377
Reserved GDT blocks at 229378-229504
Block bitmap at 136 (bg #0 + 136), csum 0x5bd8cca0
Inode bitmap at 144 (bg #0 + 144), csum 0x00000000
Inode table at 3729-4240 (bg #0 + 3729)
32639 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
Free blocks: 229505-262143
Free inodes: 57345-65536
1.1 ext4文件系统信息表
(二)ext4 磁盘布局
从上面dumpe2fs的数据上我们可以看出，一个1GB大小的空间，ext4 文件系统将它分隔成了0~7的8个Group。
ext4 的总体磁盘布局如下：
图2.1 ext4总体布局
其中，每个Group中又有superblock、Group descriptors、bitmap、Inode table、usrer data、还有一些保留空间，细分之后的空间布局如下：
图2.2 ext4 group 布局
从上图可以看出：
- Backup superblock、Group descriptors、Reserved GDT 是分布在1、3、5、7 这几个Group中，2、4、6Group并没有这些信息。
- Block bitmap、Inode bitmap、Inode table 这些元文件在每个Group中的位置并不一样，而是相差1个Block。
为什么需要这样设计？这个下面稍晚点再介绍
(三) superblock超级快
从上面《1.1 ext4文件系统信息表》中可以知道Primary superblock在第0号block，每个block的大小为4096Byte。
用hexdump 命令查看超级块的数据
biao@ubuntu:~/test/ext4$ hexdump -s 0 -n 4096 -C ext4_image.img
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 00 00 01 00 00 00 04 00 33 33 00 00 97 c7 03 00 |........33......|
00000410 ed ff 00 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000420 00 80 00 00 00 80 00 00 00 20 00 00 9c c1 5d 66 |......... ....]f|
00000430 00 d0 5f 66 02 00 ff ff 53 ef 01 00 01 00 00 00 |.._f....S.......|
00000440 81 5b 50 66 00 00 00 00 00 00 00 00 01 00 00 00 |.[Pf............|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00000460 c2 02 00 00 6b 04 00 00 01 69 49 8e f5 f7 4f b8 |....k....iI...O.|
00000470 9e 9e 53 20 88 e4 13 33 00 00 00 00 00 00 00 00 |..S ...3........|
00000480 00 00 00 00 00 00 00 00 2f 68 6f 6d 65 2f 62 69 |......../home/bi|
00000490 61 6f 2f 74 65 73 74 2f 65 78 74 34 2f 65 78 74 |ao/test/ext4/ext|
000004a0 34 5f 73 69 6d 75 6c 61 74 6f 72 00 00 00 00 00 |4_simulator.....|
000004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7f 00 |................|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 0f af 0e 8c |................|
000004f0 f3 85 4e cd b3 a4 db 2a 33 29 e1 21 01 01 40 00 |..N....*3).!..@.|
00000500 0c 00 00 00 00 00 00 00 81 5b 50 66 0a f3 01 00 |.........[Pf....|
........
biao@ubuntu:~/test/ext4$
对超级块的部分数据进行解析：
表3.1 superblock参数解析
从上表可以看出superblock的主要内容有：
文件系统信息、块大小和块组信息、Inode 相关信息、文件系统大小和使用情况、日志相关信息、挂载信息、校验和和备份信息。
其实使用dumpe2fs命令查看的ext4文件系统信息就是从superblock上的数据解析而来。
除了Primary superblock，还在不同的group中有备份superblock，其内容与Primary superblock原始数据相同，Primary superblock损坏的时候可以从备份区恢复回来。
(四) Group descriptors组描述
在 ext4 文件系统中，Group Descriptor(块组描述符)是一个关键的结构，用于描述和管理文件系统的块组(Block Group)。每个块组包含文件系统中的一部分数据块和 inode，并且有自己的元数据来管理这些资源。Group Descriptor 在超级块之后紧随其后，是文件系统的组织和管理的核心部分
从上面《1.1 ext4文件系统信息表》中可以知道group0 的 Group descriptors 在第1个数据块中，其大小为1个block
group 0 中 Group descriptors 的数据如下：
biao@ubuntu:~/test/ext4$ hexdump -s 4096 -n 4096 -C ext4_image.img
00001000 81 00 00 00 89 00 00 00 91 00 00 00 65 6f f0 1f |............eo..|
00001010 03 00 04 00 00 00 00 00 cf 34 d6 1e f0 1f 9b f1 |.........4......|
00001020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001030 00 00 00 00 00 00 00 00 fc 8e f9 49 00 00 00 00 |...........I....|
00001040 82 00 00 00 8a 00 00 00 91 02 00 00 b5 79 fd 1f |.............y..|
00001050 03 00 04 00 00 00 00 00 c2 fd 0a 43 fd 1f c2 4a |...........C...J|
00001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001070 00 00 00 00 00 00 00 00 8e a7 8c 58 00 00 00 00 |...........X....|
.........
biao@ubuntu:~/test/ext4$
对Group descriptors 的数据进行解析，可以看到详细当前group的详细信息。
图4.1 Group_descriptors参数解析
一个Group descriptors 占用一个block,它不仅仅记录自己Group上的信息，还包括了其它group的Group descriptors
(五) Block bitmap块位图
Block bitmap 块位图用于管理块组(Block Group)中的数据块,Block Bitmap 记录了块组中每个块的使用状态，标识哪些块是已使用的，哪些块是空闲的,里面数据是按位标记，为1表示该块已经被使用。
查看Block bitmap中的数据
biao@ubuntu:~/test/ext4$ hexdump -s 528384 -n 4096 -C ext4_image.img
00081000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00081210 ff ff ff 07 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00081220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00082000
biao@ubuntu:~/test/ext4$
(六) Inode bitmap索引节点位图
与Block bitmap工作原理类似，Inode bitmap 是用于管理块组(Block Group)中的inode。Inode Bitmap记录了块组中每个inode的使用状态，标识哪些inode是已使用的，哪些inode是空闲的。
biao@ubuntu:~/test/ext4$ hexdump -s 561152 -n 4096 -C ext4_image.img
00089000 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00089010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00089400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
0008a000
biao@ubuntu:~/test/ext4$
(七) Inode table索引节点表
(1)索引节点介绍
索引节点表是相对比较复杂的一个元文件，从上面《1.1 ext4文件系统信息表》我们可以知道：
Inode size: 256
Inode table at 145-656 (+145)
- 一个索引节点的大小为256Byte
- 从 Group 0信息中可以知道Group 0 的索引表位置在145-656 块的位置
查看索引节点信息：
biao@ubuntu:~/test/ext4$ hexdump -s 593920 -n 4096 -C ext4_image.img
00091000 00 00 00 00 00 00 00 00 81 5b 50 66 81 5b 50 66 |.........[Pf.[Pf|
00091010 81 5b 50 66 00 00 00 00 00 00 00 00 00 00 00 00 |.[Pf............|
00091020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00091070 00 00 00 00 00 00 00 00 00 00 00 00 6f 16 00 00 |............o...|
00091080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00091100 ed 41 00 00 00 10 00 00 78 15 61 66 e5 5d 50 66 |.A......x.af.]Pf|
00091110 e5 5d 50 66 00 00 00 00 00 00 07 00 08 00 00 00 |.]Pf............|
00091120 00 00 08 00 04 00 00 00 0a f3 01 00 04 00 00 00 |................|
00091130 00 00 00 00 00 00 00 00 01 00 00 00 91 10 00 00 |................|
00091140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00091170 00 00 00 00 00 00 00 00 00 00 00 00 fa d3 00 00 |................|
00091180 20 00 98 7a 60 ea ef 8e 60 ea ef 8e 78 f5 3f a0 | ..z`...`...x.?.|
00091190 81 5b 50 66 00 00 00 00 00 00 00 00 00 00 00 00 |.[Pf............|
000911a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00091270 00 00 00 00 00 00 00 00 00 00 00 00 8d 16 00 00 |................|
00091280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
对第2个索引节点的参数进行解析：
图7.1 Inode table参数解析
在ext4文件系统中，0~11号索引是特殊定义的索引节点：
图7.2 特殊索引节点
(2)inode.i_block介绍
在 ext4 文件系统中，inode 是一个数据结构，代表文件系统中的每个文件和目录。每个 inode 包含了有关文件的元数据，例如文件大小、权限、所有者信息等。inode.i_block 是 inode 结构中用于指向文件数据块的字段，是文件系统如何找到并访问文件内容的核心部分.
inode.i_block 是 ext4 文件系统中确保文件数据高效存储和访问的关键组件,i_block里的数据类型，需要根据i_flags中的参数来确认，上面《图7.1 Inode table参数解析》i_flags 的值是0x080000，同使用的是 Inode uses extents (EXT4_EXTENTS_FL)
iblock的长度是60字节，我们下面通过iblock里的参数找到该inode对应文件所在的block。
(3)通过inode定位到文件block
文件系统中文件信息如下：
root@ubuntu:/home/biao/test/ext4/ext4_simulator# tree
.
├── lost+found
├── test1
│ └── 0000.media
├── test2
│ └── 0011.media
├── test3
│ └── 0022.media
└── test4
└── 0033.media
5 directories, 4 files
root@ubuntu:/home/biao/test/ext4/ext4_simulator#
如果我们要找到0033.media文件所在block,我们先通过stat 查看0033.media 的inode节点
biao@ubuntu:~/test/ext4/ext4_simulator/test4$ stat 0033.media
File: 0033.media
Size: 1662591 Blocks: 3248 IO Block: 4096 regular file
Device: 719h/1817d Inode: 16 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ biao) Gid: ( 1000/ biao)
Access: 2024-06-05 10:39:09.000000000 +0800
Modify: 2024-05-14 01:01:26.000000000 +0800
Change: 2024-06-05 10:39:09.423416410 +0800
Birth: -
biao@ubuntu:~/test/ext4/ext4_simulator/test4$
定位到索引所在的位置：
145 * 4096 +（16-1）*256 = 593,920 + 3,840 = 597,760 = 0x91F00
索引节点数据
*
00091f00 a4 81 e8 03 7f 5e 19 00 cd cf 5f 66 cd cf 5f 66 |.....^...._f.._f|
00091f10 66 47 42 66 00 00 00 00 e8 03 01 00 b0 0c 00 00 |fGBf............|
00091f20 00 00 08 00 01 00 00 00 0a f3 01 00 04 00 00 00 |................|
00091f30 00 00 00 00 00 00 00 00 96 01 00 00 b5 84 00 00 |................|
00091f40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
i_block 的偏移量是0x28,对i_block的数据进行解析：
图7.4 0033.media i_block
将逻辑块0开始的0x196个block映射到物理0x84b5开始的0x196个物理块中
0x84b5 = 33973
33973 * 4096 = 139,153,408 = 0x84B 5000
查看文件系统的0x84b5 block数据，与0033.media文件的数据是相同的
第 0x84b5 block
biao@ubuntu:~/test/ext4$ hexdump -s 139153408 -n 4096 -C ext4_image.img
084b5000 01 00 00 00 25 25 01 00 7a 34 9e 74 8f 01 00 00 |....%%..z4.t....|
084b5010 8c d1 0f f2 ff ff ff ff 00 00 00 01 40 01 0c 01 |............@...|
084b5020 ff ff 01 40 00 00 03 00 90 00 00 03 00 00 03 00 |...@............|
084b5030 96 bc 09 00 00 00 01 42 01 01 01 40 00 00 03 00 |.......B...@....|
084b5040 90 00 00 03 00 00 03 00 96 a0 01 20 20 05 11 67 |........... ..g|
084b5050 be e4 4a 17 25 05 05 05 e1 00 00 03 00 01 00 00 |..J.%...........|
084b5060 03 00 14 2f 84 02 08 00 00 00 01 44 01 c0 73 c0 |.../.......D..s.|
084b5070 c6 d9 00 00 00 01 26 01 ac 39 80 1f cd 51 b5 b2 |......&..9...Q..|
084b5080 70 02 84 80 26 99 cd b5 f6 00 cf a3 06 b7 71 6b |p...&.........qk|
0033.media
biao@ubuntu:~/test/ext4/ext4_simulator/test4$ hexdump -s 0 -n 4096 -C 0033.media
00000000 01 00 00 00 25 25 01 00 7a 34 9e 74 8f 01 00 00 |....%%..z4.t....|
00000010 8c d1 0f f2 ff ff ff ff 00 00 00 01 40 01 0c 01 |............@...|
00000020 ff ff 01 40 00 00 03 00 90 00 00 03 00 00 03 00 |...@............|
00000030 96 bc 09 00 00 00 01 42 01 01 01 40 00 00 03 00 |.......B...@....|
00000040 90 00 00 03 00 00 03 00 96 a0 01 20 20 05 11 67 |........... ..g|
00000050 be e4 4a 17 25 05 05 05 e1 00 00 03 00 01 00 00 |..J.%...........|
00000060 03 00 14 2f 84 02 08 00 00 00 01 44 01 c0 73 c0 |.../.......D..s.|
00000070 c6 d9 00 00 00 01 26 01 ac 39 80 1f cd 51 b5 b2 |......&..9...Q..|
00000080 70 02 84 80 26 99 cd b5 f6 00 cf a3 06 b7 71 6b |p...&.........qk|
(八) Directory Entries目录项
(1)根目录
通过上面《图7.2 特殊索引节点》我们知道根目录的inode是2，查看根目录的索引节点位置：
根目录 inode 位置
145 * 4096 +（2-1）*256 = 593,920 + 256 = 594,176 = 0x91100
根目录 inode 数据
*
00091100 ed 41 00 00 00 10 00 00 77 be 5f 66 e5 5d 50 66 |.A......w._f.]Pf|
00091110 e5 5d 50 66 00 00 00 00 00 00 07 00 08 00 00 00 |.]Pf............|
00091120 00 00 08 00 04 00 00 00 0a f3 01 00 04 00 00 00 |................|
00091130 00 00 00 00 00 00 00 00 01 00 00 00 91 10 00 00 |................|
00091140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
图8.1 根目录inode
通过inode 上i_block信息我们可以知道,根目录inode是将逻辑块0开始的1个block映射到物理块号0x1091开始的1个block
0x1091 = 4,241
4,241 * 4096 = 17,371,136 = 0x109 1000
biao@ubuntu:~/test/ext4$ hexdump -s 17371136 -n 4096 -C ext4_image.img
01091000 02 00 00 00 0c 00 01 02 2e 00 00 00 02 00 00 00 |................|
01091010 0c 00 02 02 2e 2e 00 00 0b 00 00 00 14 00 0a 02 |................|
01091020 6c 6f 73 74 2b 66 6f 75 6e 64 00 00 0c 00 00 00 |lost+found......|
01091030 10 00 05 02 74 65 73 74 31 00 00 00 01 20 00 00 |....test1.... ..|
01091040 10 00 05 02 74 65 73 74 32 00 00 00 02 20 00 00 |....test2.... ..|
01091050 10 00 05 02 74 65 73 74 33 00 00 00 03 20 00 00 |....test3.... ..|
01091060 98 0f 05 02 74 65 73 74 34 00 00 00 00 00 00 00 |....test4.......|
01091070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01091ff0 00 00 00 00 00 00 00 00 0c 00 00 de 67 85 5b 11 |............g.[.|
01092000
biao@ubuntu:~/test/ext4$
可以看到根目录上的所有信息，下面是对根目录的目录项进行解析
图8.2 根目录项解析
同样的方法，可以定位到各子目录上的信息。
(九) ext4 实现原理
1. 文件系统初始化和挂载
- 挂载文件系统时，内核读取超级块以获取文件系统的基本信息。
- 内核读取块组描述符，以了解每个块组中元数据的布局。
2. 创建文件
- 查找空闲 inode：通过检查 inode 位图找到一个空闲的 inode，并在 inode 位图中标记为已使用。
- 分配数据块：通过检查块位图找到空闲的数据块，并在块位图中标记为已使用。
- 更新 inode：将新文件的元数据写入 inode 表中的相应位置。
- 更新目录项：在目标目录的 inode 数据块中添加一个新的目录项，包含文件名和对应的 inode 号。
3. 读取文件
- 查找 inode：根据文件名在目录项中查找对应的 inode 号，然后读取 inode 表中的相应 inode。
- 读取数据块：根据 inode 中的块指针，读取文件数据块。
4. 删除文件
- 释放数据块：根据 inode 中的块指针，更新块位图以标记这些块为空闲。
- 释放 inode：在 inode 位图中将该 inode 标记为空闲。
- 更新目录项：从目录的 inode 数据块中删除相应的目录项。
5. 文件系统检查和修复
fsck工具利用超级块、块组描述符、块位图和 inode 位图来检查文件系统的一致性。- 修复损坏的结构，例如修复丢失的块或 inode 标记。
(十) 优缺点
优点
- 性能改进：
- 延迟分配：数据块分配延迟到实际写入时进行，从而优化文件碎片化和提高写入性能。
- 多块分配：同时分配多个块，提高大文件写入速度，减少碎片。
- 快速 fsck：改进的文件系统检查工具
fsck能够更快地进行一致性检查，减少系统恢复时间。
- 大文件和大文件系统支持：
- 支持单个文件最大 16 TB 和文件系统最大 1 EB 的存储容量，适合现代大规模存储需求。
- 向后兼容：
- Ext4 文件系统可以向后兼容 Ext3 和 Ext2，允许用户在无需格式化的情况下从这些文件系统无缝迁移到 Ext4。
- 日志功能：
- 支持元数据日志和数据日志，有助于提高文件系统的可靠性和防止数据损坏。
- 在线碎片整理：
- 支持在线碎片整理工具，可以在系统运行时整理文件碎片，提高文件访问速度。
- Extent：
- 使用 extent 来代替传统的块映射方式，提高了大文件的存储效率，减少了文件碎片。
- 防止文件系统崩溃：
- 使用日志和其他安全机制，确保文件系统崩溃后能快速恢复。
缺点
- 碎片整理效率：
- 尽管支持在线碎片整理，但与一些现代文件系统（如 Btrfs、ZFS）相比，Ext4 的碎片整理效率仍然较低。
- 新特性限制：
- 虽然 Ext4 引入了许多改进，但由于其设计上依赖于传统的 Ext 系列架构，它在引入某些现代文件系统的新特性（如快照、数据去重、内置 RAID 等）时受到限制。
- 文件系统扩展：
- 尽管 Ext4 支持非常大的文件和文件系统，但在线扩展文件系统的操作复杂度较高，尤其是在需要缩小文件系统时。
- 元数据缓存：
- Ext4 在缓存机制上的设计导致在高负载环境下，元数据操作（如创建或删除大量小文件）的性能可能受到影响。
结尾
上面只是简单的介绍了ext4文件系统的基础内容，一些更加详细的内容，比如日志、碎片整理、软连接与硬连接等等都还没有介绍，受篇幅限制，这些以后再介绍吧。
---------------------------End---------------------------
如需获取更多内容
请关注 liwen01 公众号
文件系统(六)：一文看懂linux ext4文件系统工作原理的更多相关文章
- 一文看懂汽车电子ECU bootloader工作原理及开发要点
随着半导体技术的不断进步(按照摩尔定律),MCU内部集成的逻辑功能外设越来越多,存储器也越来越大.消费者对于汽车节能(经济和法规对排放的要求)型.舒适性.互联性.安全性(功能安全和信息安全)的要求越来 ...
- Nginx源码分析：3张图看懂启动及进程工作原理
编者按:高可用架构分享及传播在架构领域具有典型意义的文章,本文由陈科在高可用架构群分享.转载请注明来自高可用架构公众号「ArchNotes」. 导读:很多工程师及架构师都希望了解及掌握高性能服务器 ...
- 从零入门 Serverless | 一文搞懂函数计算及其工作原理
作者 | 孔德慧(夏莞) 阿里云函数计算开发工程师 什么是函数计算 大家都了解,Serverless 并不是没有服务器,而是开发者不再需要关心服务器.下图是一个应用从开发到上线的对比图: 在传统 Se ...
- 【转帖】一文看懂docker容器技术架构及其中的各个模块
一文看懂docker容器技术架构及其中的各个模块 原创 波波说运维 2019-09-29 00:01:00 https://www.toutiao.com/a6740234030798602763/ ...
- 一文看懂大数据的技术生态圈，Hadoop，hive，spark都有了
一文看懂大数据的技术生态圈,Hadoop,hive,spark都有了 转载: 大数据本身是个很宽泛的概念,Hadoop生态圈(或者泛生态圈)基本上都是为了处理超过单机尺度的数据处理而诞生的.你可以把它 ...
- 一文看懂java io系统 (转)
出处: 一文看懂java io系统 学习java IO系统,重点是学会IO模型,了解了各种IO模型之后就可以更好的理解java IO Java IO 是一套Java用来读写数据(输入和输出)的A ...
- 一文看懂web服务器、应用服务器、web容器、反向代理服务器区别与联系
我们知道,不同肤色的人外貌差别很大,而双胞胎的辨识很难.有意思的是Web服务器/Web容器/Web应用程序服务器/反向代理有点像四胞胎,在网络上经常一起出现.本文将带读者对这四个相似概念如何区分. 1 ...
- 一文看懂https如何保证数据传输的安全性的【转载、收藏】
一文看懂https如何保证数据传输的安全性的 一文看懂https如何保证数据传输的安全性的 大家都知道,在客户端与服务器数据传输的过程中,http协议的传输是不安全的,也就是一般情况下http是明 ...
- [转帖]一文看懂web服务器、应用服务器、web容器、反向代理服务器区别与联系
一文看懂web服务器.应用服务器.web容器.反向代理服务器区别与联系 https://www.cnblogs.com/vipyoumay/p/7455431.html 我们知道,不同肤色的人外貌差别 ...
- [转帖] 一文看懂："边缘计算"究竟是什么？为何潜力无限？
一文看懂:"边缘计算"究竟是什么?为何潜力无限? 转载cnbeta 云计算 雾计算 边缘计算... 知名创投调研机构CB Insights撰文详述了边缘计算的发展和应用前景 ...
随机推荐
- 力扣299(java)-猜数字游戏（中等）
题目: 你在和朋友一起玩 猜数字(Bulls and Cows)游戏,该游戏规则如下: 写出一个秘密数字,并请朋友猜这个数字是多少.朋友每猜测一次,你就会给他一个包含下述信息的提示: 猜测数字中有多少 ...
- iLogtail开源之路
简介: 2022年6月底,阿里云iLogtail代码完整开源,正式发布了完整功能的iLogtail社区版.iLogtail作为阿里云SLS官方标配的采集器,多年以来一直稳定服务阿里集团.蚂蚁集团以及众 ...
- Serverless 选型：深度解读 Serverless 架构及平台选择
作者 | 悟鹏 阿里巴巴技术专家 导读:本文尝试以日常开发流程为起点,分析开发者在每个阶段要面对的问题,然后组合解决方案,提炼面向 Serverless 的开发模型,并与业界提出的 Serverle ...
- 基于 RocketMQ Prometheus Exporter 打造定制化 DevOps 平台
简介: 本文将对 RocketMQ-Exporter 的设计实现做一个简单的介绍,读者可通过本文了解到 RocketMQ-Exporter 的实现过程,以及通过 RocketMQ-Exporter 来 ...
- [Py] Python 接口数据用 pandas 高效写入 csv
通过 pandas 把 dict 数据封装,调用接口方法写入 csv 文件. import pandas as pd data = [{"name": "a"} ...
- 2.docker-compose安装prometheus
一.docker-compose安装 前期准备 # docker配置文件 sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json < ...
- 21°C的冬天
2023-12-08 16:15:36 星期五 标题没有在胡说,今天穿着初秋的衣服还嫌热,尤其是蒋震图书馆的空调更是燥热. 明天就去考教资面试了,但是一点也没有学习的兴趣,今天下午四点就写完了这周所有 ...
- 【RMAN】一些参数温故知新
RMAN全局参数: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 21 DAYS 这样相当于保留备份的窗口为21天,说明,从今天起的前21天的数据都 ...
- ElasticView 是一款用来监控elasticsearch状态和操作elasticsearch索引的web可视化工具。
ElasticView 是一款用来监控elasticsearch状态和操作elasticsearch索引的web可视化工具. 它由golang开发而成,具有部署方便,占用内存小等优点 es连接树管理( ...
- Sublime Text 3 初试牛刀
每次我在其他视频网站上看学习视频的时候,看着老师用的编辑器高大上档次,而我一般用Notepad,和Dreamweaver去编辑网页,需要每一行代码,打进去,效率低.最近看到sublime编辑器,在网上 ...