一文看懂linux ext4文件系统工作原理

news2024/11/17 13:46:08

前言

Linux系统中的ext2、ext3、ext4 文件系统,它们都有很强的向后和向前兼容性,可以在数据不丢失的情况下进行文件系统的升级。目前ext4是一个相对较成熟、稳定且高效的文件系统,适用于绝大部分规模和需求的Linux环境。

ext4它突出的特点有:数据分段管理、多块分配、延迟分配、持久预分配、日志校验、支持更大的文件系统和文件大小。

ext4文件系统的具体实现比较复杂,本文尝试用比较简单的方式用一篇文章的篇幅来简单地介绍一下它的工作原理。

(一)创建ext文件系统

为了分析ext4 文件系统的内部结构和原理,这里我们在Linux中创建一个ext4文件系统镜像,然后通过loop虚拟设备将ext4镜像文件挂载到某个目录上。具体实现步骤如下:

  1. 创建一个1GB的文件

dd if=/dev/zero of=./ext4_image.img bs=1M count=1024

  1. 将这个文件格式化成 ext4 文件系统格式

mkfs.ext4 ext4_image.img

  1. 通过Linux的loop虚拟设备将文件挂载到目录上

sudo mount -o loop ext4_image.img /home/biao/test/ext4/ext4_simulator

  1. 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

(二)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 布局

从上图可以看出:

  1. Backup superblock、Group descriptors、Reserved GDT 是分布在1、3、5、7 这几个Group中,2、4、6Group并没有这些信息。

  2. 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 = 3397333973 * 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,2414,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 标记。

(十) 优缺点

优点

  1. 性能改进延迟分配:数据块分配延迟到实际写入时进行,从而优化文件碎片化和提高写入性能。多块分配:同时分配多个块,提高大文件写入速度,减少碎片。快速 fsck:改进的文件系统检查工具 fsck 能够更快地进行一致性检查,减少系统恢复时间。

  2. 大文件和大文件系统支持:支持单个文件最大 16 TB 和文件系统最大 1 EB 的存储容量,适合现代大规模存储需求。

  3. 向后兼容:Ext4 文件系统可以向后兼容 Ext3 和 Ext2,允许用户在无需格式化的情况下从这些文件系统无缝迁移到 Ext4。

  4. 日志功能:支持元数据日志和数据日志,有助于提高文件系统的可靠性和防止数据损坏。

  5. 在线碎片整理:支持在线碎片整理工具,可以在系统运行时整理文件碎片,提高文件访问速度。

  6. Extent:使用 extent 来代替传统的块映射方式,提高了大文件的存储效率,减少了文件碎片。

  7. 防止文件系统崩溃:使用日志和其他安全机制,确保文件系统崩溃后能快速恢复。

缺点

  1. 碎片整理效率:尽管支持在线碎片整理,但与一些现代文件系统(如 Btrfs、ZFS)相比,Ext4 的碎片整理效率仍然较低。

  2. 新特性限制:虽然 Ext4 引入了许多改进,但由于其设计上依赖于传统的 Ext 系列架构,它在引入某些现代文件系统的新特性(如快照、数据去重、内置 RAID 等)时受到限制。

  3. 文件系统扩展:尽管 Ext4 支持非常大的文件和文件系统,但在线扩展文件系统的操作复杂度较高,尤其是在需要缩小文件系统时。

  4. 元数据缓存:Ext4 在缓存机制上的设计导致在高负载环境下,元数据操作(如创建或删除大量小文件)的性能可能受到影响。

结尾

上面只是简单的介绍了ext4文件系统的基础内容,一些更加详细的内容,比如日志、碎片整理、软连接与硬连接等等都还没有介绍,受篇幅限制,这些以后再介绍吧。

文章转载自:liwen01

原文链接:https://www.cnblogs.com/liwen01/p/18237062

体验地址:引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1812267.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

修改SubVI的LabVIEW默认搜索路径

在启动顶级VI后&#xff0c;LabVIEW可能会遇到找不到subVI的情况。这通常是由于subVI的路径发生了变化或没有被正确配置。 LabVIEW默认搜索路径 默认情况下&#xff0c;LabVIEW会按以下顺序搜索文件位置&#xff08;*表示LabVIEW将搜索子目录&#xff09;&#xff1a; <t…

PS系统教程15

仿制图章与修饰照片 仿制图章工具使用&#xff08;S&#xff09;使用方法&#xff1a;按住Alt键进行采样选定照片新建图层&#xff08;方便修改&#xff09;按住Alt键&#xff0c;进行吸取进行采样复制 下面那个石柱是我们复制的石柱 多余的部分用历史画笔工具涂抹掉一部分 案…

外汇天眼:Brighter Super 选择 State Street 作为托管和管理合作伙伴

State Street Corporation&#xff08;纽约证券交易所代码&#xff1a;STT&#xff09;今日宣布&#xff0c;其已被选为 Brighter Super 成员所投资的超过300亿澳元基金的托管人和管理员。 State Street 将为 Brighter Super 涵盖多种资产类别的130多个投资组合提供广泛的服务…

一文带你入门 - Qt绘图QPainter

QPaintEvent绘图事件: QPaintEvent 是 Qt 框架中一个重要的事件类&#xff0c;专门用于处理绘图事件。当 Qt 视图组件需要重绘自己的一部分时&#xff0c;就会产生 QPaintEvent 事件。这通常发生在以下几种情况&#xff1a; 1. 窗口第一次显示时&#xff1a;当窗口或控件第一次…

探秘C++ STL中的Stack与Queue:数据结构的艺术与实践

在C的世界里&#xff0c;标准模板库(STL)无疑是一颗璀璨的明珠&#xff0c;它不仅极大地丰富了C的生态系统&#xff0c;更为开发者提供了强大的工具箱。其中&#xff0c;stack和queue作为两种基础而重要的数据结构&#xff0c;扮演着不可或缺的角色。本文将深入剖析这两个容器适…

国内著名的四个“大模型”

关于您提到的国内四大模型&#xff0c;这里为您详细介绍&#xff1a; 文心大模型&#xff1a;文心大模型是百度自主研发的产业级知识增强大模型。它以创新性的知识增强技术为核心&#xff0c;从单模态大模型发展到跨模态&#xff0c;从通用基础大模型到跨领域、跨行业&#xff…

英特尔为何大力押注边缘AI

正如近期历史上所有AI领域的情况一样&#xff0c;边缘AI部署也未能免受指数级增长的影响。 随着钟摆从集中式部署转向分布式部署&#xff0c;AI推动了边缘计算的大部分增长&#xff0c;组织越来越多地希望将AI算法和模型部署到本地边缘设备上&#xff0c;消除了不断依赖云基础设…

程序员们,如何预防大龄危机?

困境 在中国&#xff0c;程序员到了35岁&#xff0c;基本是一个坎&#xff0c;如果你还是通过常规的招聘网或者猎头去找工作&#xff0c;能拿到offer的比例相对低&#xff0c;因为跟新手程序员比&#xff0c;你没有明显的优势。 论薪资&#xff1a; 大龄程序员的薪资要求应该…

3.Nginx配置文件基本介绍

nginx配置文件所在路径&#xff1a;/usr/local/nginx/conf/nginx.conf nginx配置文件有三块&#xff1a; 1.全局块 从配置文件开始到events块之间的内容&#xff0c;主要会设置一些影响nginx服务器整体运行的配置指令。 配置运行nginx服务器的用户(组)允许生成的worker pro…

stm32 Listings和Objects文件夹目录设置

我们在test.c文件里面输入如下代码&#xff1a; #include "sys.h" #include "usart.h" #include "delay.h" int main(void) { u8 t0; Stm32_Clock_Init(9); //系统时钟设置 delay_init(72); //延时初始化 uart_i…

探索Android异步编程:Coroutine与RxJava的差异及实例分析

探索Android异步编程&#xff1a;Coroutine与RxJava的差异及实例分析 在Android开发中&#xff0c;处理异步操作&#xff08;例如网络请求或数据库操作&#xff09;是一项常见任务。传统的回调方法虽然能解决问题&#xff0c;但代码复杂且难以维护。为了解决这些问题&#xff…

修复错误提示“由于找不到msvcr120.dll,无法继续执行代码”的几种方法

当你的电脑出现“由于找不到msvcr120.dll,无法继续执行代码”的错误提示时&#xff0c;首先&#xff0c;需要确定您的系统中是否缺少或损坏了msvcr120.dll文件。这可以通过运行程序时收到类似“无法启动程序&#xff0c;因为msvcr120.dll丢失”或“找不到msvcr120.dll”等错误信…

6.结构体

目录 一、普通结构体&#xff08;struct&#xff09;1.1 说明1.2 举例1&#xff09;结构体定义及访问2&#xff09;结构体初化的简单写法3&#xff09;结构体更新语法 二、元组结构体&#xff08;tuple struct&#xff09;2.1 概念2.2 示例 三、类单元结构体&#xff08;unit-l…

贪 吃 蛇

简介 简易贪吃蛇&#xff0c;使用 javax.swing 组件构建游戏界面&#xff0c;通过监听键盘按键实现游戏操纵。 功能设计 按1 - 开始游戏按2 - 重新开始按3 - 暂停/继续按Esc-退出游戏统计吃到的苹果个数&#xff08;得分&#xff09;难度控制&#xff0c;得分超过阈值时难度…

计算机内存分类

1&#xff0c;非易失性存储器。 断电时&#xff0c;存储器的内容不会丢失&#xff0c;并且 加电时再次可用。这对于处理器启动或重启时使用的引导代码是必需的。 o ROM&#xff1a;只读存储器&#xff1b;此存储器的内容在制造过程中定义 设备。一旦发生错误&#xff0c;芯片…

推荐系统学习笔记(五)-----双塔模型

目录 双塔模型 训练 pointwise训练 pairwise训练 listwise训练 双塔模型 矩阵补充模型只用到了用户id和物品id&#xff0c;其余属性没有用上 用户属性也可以这样处理 用户塔和物品塔各输出一个向量&#xff0c;两个向量的余弦相似度作为兴趣的预估值 训练 第一种&#x…

VFP发送邮件有哪些配置要求?如何使用VFP?

VFP发送邮件支持的邮件服务器&#xff1f;邮件发送功能怎么优化&#xff1f; 在如今的互联网时代&#xff0c;应用程序发送邮件功能几乎是不可或缺的&#xff0c;VFP也不例外。然而&#xff0c;要实现VFP发送邮件&#xff0c;需要了解并配置相关的要求和步骤。AokSend将详细介…

如何查看个人大数据信用报告?查询报告哪家好呢?

大数据信用报告是现代社会中非常重要的信用评估工具&#xff0c;对于个人来说也具有非常重要的意义。那么&#xff0c;如何查看个人大数据信用报告?查询报告哪家好呢?本文将为您介绍。 首先&#xff0c;查看个人大数据信用报告需要了解报告的内容和格式 一般来说&#xff0c;…

【Python】Flask问答系统Demo项目

学习视频 我是跟着知了传课学的Flask&#xff0c;起初了解Flask还是GPT告诉我的&#xff0c;现在可以说用Flask做后端是真的方便&#xff01; https://www.bilibili.com/video/BV17r4y1y7jJ 项目结构与下载 FlaskOA&#xff08;项目文件夹&#xff09; │ app.py │ conf…

skywalking9.4 链路追踪

下载&#xff0c;很慢很慢很慢&#xff01;&#xff01;&#xff01;&#xff01; jdk 使用jdk17 skywalking-apm 9.4 java-agent 9.0 idea 本地开发配置 第1行配置按实际来&#xff1b; 第2行自定义&#xff0c;一般和微服务名称相同&#xff1b; 第3行ip写安装的机器ip,端…