正文 

当前位置： 首页 > java > java教程

ext2文件系统

AlanTu AlanTu     2022-10-15     690

关键词：

 很久以来，就想写一篇关于ext 家族文件系统的文章，源于我刚工作的时候，曾经一不小心rm -rf，误删除了很多文件，当时真想有个数据恢复软件能帮我把数据回复了。当然学习数据恢复，首先要学习文件系统。最近工作原因，好长时间没看学习Linux kernel 相关的东西，感觉面目可憎。扯远了，开始我们的ext2 文件系统的探索之旅。

 
    那些介绍ext2特征的套话我就不说了，任何一本靠谱的linux教程中都可以找到，我们直接单刀直入，开始探索。
 
    首先生成一个ext2文件系统。我在我磁盘空间有限的Ubuntu中，划出500M的空间来从头学习ext2 文件系统。
 
    dd命令用来创建一个文件，不多说了，通过执行这个dd命令生成了一个全零的大小为512000*1KB的文件，即500MB 的文件。
 
    losetup是设定循环设备（loop service）的，循环设备可以将文件模拟成块设备。然后在块设备上建立我们的ext2文件系统，来进行我们的学习。所以下面用mke2fs命令将loop设备格式化成ext2文件系统。 Oh，yeah，我们终于有了ext2文件系统。
 
    这里需要强调下，我们调用了mke2fs的默认选项其中：
 
  1. [email protected]:~# dd if=/dev/zero of=bean bs=1K count=512000
  2. 记录了512000 0 的读入
  3. 记录了512000 0 的写出
  4. 524288000字节(524 MB)已复制，9.40989 秒，55.7 MB/秒
  5. [email protected]:~# ll bean
  6. -rw-r--r-- 1 root root 524288000 2012-07-06 22:24 bean
  7. [email protected]:~# ll -h bean
  8. -rw-r--r-- 1 root root 500M 2012-07-06 22:24 bean
  9. [email protected]:~# 
  10. [email protected]:~# 
  11. [email protected]:~# losetup /dev/loop0 bean
  13. root[email protected]:~# cat /proc/partitions 
  14. major minor #blocks name
  16.    7 0 512000 loop0
  17.    8 0 312571224 sda
  18.    8 1 49182966 sda1
  19. .......
  21. [email protected]:~# mke2fs /dev/loop0
  22. mke2fs 1.41.11 (14-Mar-2010)
  23. 文件系统标签=
  24. 操作系统:Linux
  25. 块大小=1024 (log=0)
  26. 分块大小=1024 (log=0)
  27. Stride=0 blocks, Stripe width=0 blocks
  28. 128016 inodes, 512000 blocks
  29. 25600 blocks (5.00%) reserved for the super user
  30. 第一个数据块=1
  31. Maximum filesystem blocks=67633152
  32. 63 block groups
  33. 8192 blocks per group, 8192 fragments per group
  34. 2032 inodes per group
  35. Superblock backups stored on blocks: 
  36.     8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
  38. 正在写入inode表: 完成 
  39. Writing superblocks and filesystem accounting information: 完成
  41. This filesystem will be automatically checked every 24 mounts or
  42. 180 days, whichever comes first. Use tune2fs -c or -i to override.
    但是这样还没完，我们还是不能访问我们新建的ext2文件系统，因为还没有挂载，我决定将loop 设备挂载在/mnt/bean 目录下。
       

 

  1. mkdir /mnt/bean
  2. mount -t ext2 /dev/loop0 /mnt/bean
  4. [email protected]:/mnt/bean# mount
  5. .........
  6. /dev/loop0 on /mnt/bean type ext2 (rw)
  8. [email protected]:/mnt/bean# ll
  9. 总用量 17
  10. drwxr-xr-x 3 root root 1024 2012-07-06 22:31 ./
  11. drwxr-xr-x 4 root root 4096 2012-07-06 22:32 ../
  12. drwx------ 2 root root 12288 2012-07-06 22:31 lost found/

     经过我们的努力，我们终于创建好了我们的ext2文件系统。下面需要讲讲ext2文件系统的结构是什么样的了。


    下面这张图是经典的ext2文件系统的结构图。网上到处可以找到这种类似的图片，但是我非要画这个图片的原因是为了澄清2个问题：
 
    1 并不是所有的块组都有超级块和快组描述符。
    2 块组描述符GDT并不是只管理自己这个块组的信息，相反，它管理的是所有的块组的信息。
 
技术分享图片
   (inode表和数据块的个数不一定相等，我这个图画多少有点问题)
 
     我们知道，超级块是很重要的，因为它告诉了linux 这个块设备是怎样组织的，它告诉linux我这个文件系统是什么文件系统，每个块的大小是多大（1024、2048 or 4096），每个块组有多少个块，inode占多少个字节。等等的信息。正是因为超级块很重要，所以我们不能将这些信息只保存1份。试想一下，如果超级块坏掉了，而我们只有一个块组有超级块，那么就彻底完蛋了，后面接近500M的空间及里面的数据我们都没办法获得了。这是比较容易理解的。但是，是不是每个块组都要有启动块呢。这就没必要了，这也有点空间浪费。那到底把超级块放到那些块组呢？

  1. Superblock backups stored on blocks: 
  2.     8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
    这是格式化loop设备输出到终端的result信息，因为每个块组是8192个块（原因后面讲），所以第0个块组 ，第1块组，第3个块组 第5个块组，第7个块组，第9个块组，第25个块组，第27个块组，第49个块组存储有超级块。
 
    怎么计算出来的，为什么非要存在这些块组？计算规则是3 5 和7的幂，这样的块组保存超级块。
 
    解释块组描述符之前我们先看下超级块的相关信息：
       
  1. struct ext2_super_block {
  2.   __u32   s_inodes_count;
  3.   __u32   s_blocks_count;
  4.   __u32   s_r_blocks_count;
  5.   __u32   s_free_blocks_count;
  6.   __u32   s_free_inodes_count;
  7.   __u32   s_first_data_block;
  8.   __u32   s_log_block_size;
  9.   __u32   s_dummy3[7];
  10.   unsigned char s_magic[2];
  11.   __u16   s_state;
  12. ...
  14. }  
     下面我们通过debugfs来获取一下ext2的相关信息。

  1. [email protected]:/mnt/bean# dumpe2fs /dev/loop0
  2. dumpe2fs 1.41.11 (14-Mar-2010)
  3. Filesystem volume name: <none>
  4. Last mounted on: <not available>
  5. Filesystem UUID: 3bff7535-6f39-4720-9b64-1dc8cf9fe61d
  6. Filesystem magic number: 0xEF53
  7. Filesystem revision #: 1 (dynamic)
  8. Filesystem features: ext_attr resize_inode dir_index filetype sparse_super
  9. Filesystem flags: signed_directory_hash 
  10. Default mount options: (none)
  11. Filesystem state: not clean
  12. Errors behavior: Continue
  13. Filesystem OS type: Linux
  14. Inode count: 128016
  15. Block count: 512000
  16. Reserved block count: 25600
  17. Free blocks: 493526
  18. Free inodes: 128005
  19. First block: 1
  20. Block size: 1024
  21. Fragment size: 1024
  22. Reserved GDT blocks: 256
  23. Blocks per group: 8192
  24. Fragments per group: 8192
  25. Inodes per group: 2032
  26. Inode blocks per group: 254
  27. Filesystem created: Fri Jul 6 22:31:09 2012
  28. Last mount time: Fri Jul 6 22:33:28 2012
  29. Last write time: Fri Jul 6 22:33:28 2012
  30. Mount count: 1
  31. Maximum mount count: 24
  32. Last checked: Fri Jul 6 22:31:09 2012
  33. Check interval: 15552000 (6 months)
  34. Next check after: Wed Jan 2 22:31:09 2013
  35. Reserved blocks uid: 0 (user root)
  36. Reserved blocks gid: 0 (group root)
  37. First inode: 11
  38. Inode size:     128
  39. Default directory hash: half_md4
  40. Directory Hash Seed: 0140915d-91ae-43df-9d84-9536cedc0d2b
  42. Group 0: (Blocks 1-8192)
  43.   主 superblock at 1, Group descriptors at 2-3
  44.   保留的GDT块位于 4-259
  45.   Block bitmap at 260 ( 259), Inode bitmap at 261 ( 260)
  46.   Inode表位于 262-515 ( 261)
  47.   7663 free blocks, 2021 free inodes, 2 directories
  48.   可用块数: 530-8192
  49.   可用inode数: 12-2032
  50. ...
  51. Group 62: (Blocks 507905-511999)
  53.   Block bitmap at 507905 (+0), Inode bitmap at 507906 (+1)
  54.   Inode表位于 507907-508160 (+2)
  55.   3839 free blocks, 2032 free inodes, 0 directories
  56.   可用块数: 508161-511999
  57.   可用inode数: 125985-128016
     OK ,我们拿到了这些信息，但是，我怎么证明debugfs拿到的信息是对的呢。只有一个办法，我们钻到超级块里面，根据超级块数据结构，获得超级块每个字段的值，听起来很刺激吧，OK，Just DO IT。
 
  1. [email protected]:/mnt/bean# dd if=/dev/loop0 bs=1k count=261 |od -tx1 -Ax > /tmp/dump_hex
  2. 记录了261 0 的读入
  3. 记录了261 0 的写出
  4. 267264字节(267 kB)已复制，0.0393023 秒，6.8 MB/秒
  5. [email protected]:/mnt/bean# vi /tmp/dump_hex
    我将整个loop设备前面的261K字节读入了/tmp/dump_hex中。其中第0块是启动块，按下不提。第一块就是说super block。很激动，我们终于可以和传说中的超级块赤裸相见了。
 
  1. 000400 10 f4 01 00 00 d0 07 00 00 64 00 00 d6 87 07 00
  2. 000410 05 f4 01 00 01 00 00 00 00 00 00 00 00 00 00 00
  3. 000420 00 20 00 00 00 20 00 00 f0 07 00 00 5f cb f7 4f
  4. 000430 5f cb f7 4f 01 00 1a 00 53 ef 00 00 01 00 00 00
  5. 000440 25 cb f7 4f 00 4e ed 00 00 00 00 00 01 00 00 00
  6. 000450 00 00 00 00 0b 00 00 00 80 00 00 00 38 00 00 00
  7. 000460 02 00 00 00 01 00 00 00 5a 65 4b 92 fe 63 43 eb
  8. 000470 b6 86 3e f3 6e 44 19 af 00 00 00 00 00 00 00 00
  9. 000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  10. *
  11. 0004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
  12. 0004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  13. 0004e0 00 00 00 00 00 00 00 00 00 00 00 00 f9 6f 16 79
  14. 0004f0 b7 dc 4f 8a a1 a1 18 82 72 a7 d8 25 01 00 00 00
  15. 000500 00 00 00 00 00 00 00 00 25 cb f7 4f 00 00 00 00
  16. 000510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  17. *
  18. 000560 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  19. 000570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  20. *
  21. 000800 04 01 00 00 05 01 00 00 06 01 00 00 ef 1d e5 07


        最左边一列是地址，16进制。000400=1K，换句话说，就是文件第1K个字节。000800 =2K，这就是我们朝思暮想的超级块啊。我很激动，所以把整个超级块都贴上了，幸好我不是靠字数来骗稿费的人，否则咱得被鄙视死。

        再把ext2超级块的数据结构贴上，咱挨个字段比较比较，看看debugfs说的对不？
    
  1. struct ext2_super_block {
  2.   __u32 s_inodes_count;
  3.   __u32 s_blocks_count;
  4.   __u32 s_r_blocks_count;
  5.   __u32 s_free_blocks_count;
  6.   __u32 s_free_inodes_count;
  7.   __u32 s_first_data_block;
  8.   __u32 s_log_block_size;
  10. ...
  12. }
    第一个字段叫s_inodes_count， 占四个字节。OK，我们看，从1K开始前四个字节是10 f4 01 00。我们知道有little-endian和big-endian。ext2设计者为了支持文件系统的可移动，规定磁盘上一律是little-endian，数据读入内存中时，kernel来负责把格式转成cpu的本机格式。
 
    OK，是little-endian咱就明白了，不就是0x0001f410嘛 。 0x0001f410=128016,看看debugfs给我们的数据，Inode count: 128016,一模一样。
 
    再举个例子，比如，我们关心free_blocks_count，查看数据结构，free_blocks_count字段起始位置是超级块的第12字节。即00040c地址。看下的 d6 87 07 00。计算以下可以得到0x000787d6 = 493526,和debugfs 的Free blocks给出的一样。OK。看管关心什么字段，可以自己查看。通过和超级块赤裸想见，我们知道了ext2 super block的结构。

    最后总结一句，不是所有的块组都有超级块，超级块只占1个block块，没错，当blocksize为4K的时候，这个块大多数空间是浪费的。不过还好，毕竟超级块个数有限，浪费不了多少。
 
     下面讲述 块组描述符：
 
    组描述符一共32个字节，大多数的教材都会给我们一组误解，就是每个块组，都要有组描述符。事实上并不是这样。我们知道，一个组描述符只占32字节，而大多数的教材都会告诉我们，一个块组里面的组描述符占k个块，一个组描述符是用不了这么多空间的。
 
    真相只有一个，就是所有的组描述符以数组的形式存放在k个块中。也就是说，某个块组可能没有组描述符，而有组描述符的块组，k个block中存放了所有组块的组描述符。下面我来证实：
 
  1. struct ext2_group_desc
  2. {
  3.   __u32 bg_block_bitmap; /* Blocks bitmap block */
  4.   __u32 bg_inode_bitmap; /* Inodes bitmap block */
  5.   __u32 bg_inode_table; /* Inodes table block */
  6.   __u16 bg_free_blocks_count; /* Free blocks count */
  7.   __u16 bg_free_inodes_count; /* Free inodes count */
  8.   __u16 bg_used_dirs_count; /* Directories count */
  9.   __u16 bg_flags;
  10.   __u32 bg_exclude_bitmap_lo;/* Exclude bitmap for snapshots */
  11.   __u16 bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap)LSB */
  12.   __u16 bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap)LSB */
  13.   __u16 bg_itable_unused; /* Unused inodes count */
  14.   __u16 bg_checksum; /* crc16(s_uuid+grouo_num+group_desc)*/
  15. };
   
 Group 0: (Blocks 1-8192)
  主 superblock at 1, Group descriptors at 2-3
  保留的GDT块位于 4-259
  Block bitmap at 260 (+259), Inode bitmap at 261 (+260)
  Inode表位于 262-515 (+261)
  7663 free blocks, 2021 free inodes, 2 directories
  可用块数: 530-8192
  可用inode数: 12-2032
  1. Group 1: (Blocks 8193-16384)
  2.   备份 superblock at 8193, Group descriptors at 8194-8195
  3.   保留的GDT块位于 8196-8451
  4.   Block bitmap at 8452 (+259), Inode bitmap at 8453 (+260)
  5.   Inode表位于 8454-8707 (+261)
  6.   7677 free blocks, 2032 free inodes, 0 directories
  7.   可用块数: 8708-16384
  8.   可用inode数: 2033-4064
  9. Group 2: (Blocks 16385-24576)
  10.   Block bitmap at 16385 (+0), Inode bitmap at 16386 (+1)
  11.   Inode表位于 16387-16640 (+2)
  12.   7936 free blocks, 2032 free inodes, 0 directories
  13.   可用块数: 16641-24576
  14.   可用inode数: 4065-6096
    看上图，debugfs出来的信息，Group 2，并没有所谓的组描述符。而Group1，用8194和8195两个块来存储。OK，我们看下，里面存储的是什么东西。
 
    Group 0里面第2和第3块存储的是组描述符，也就说从0x000800～0x001000是组描述符块的内容。

  1. 000800 04 01 00 00 05 01 00 00 06 01 00 00 ef 1d e5 07
  2. 000810 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 块组0的组描述符
  3. -----------------------------------------------------------------------
  4. 000820 04 21 00 00 05 21 00 00 06 21 00 00 fd 1d f0 07
  5. 000830 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 块组1的组描述符
  6. -----------------------------------------------------------------------
  7. 000840 01 40 00 00 02 40 00 00 03 40 00 00 00 1f f0 07
  8. 000850 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 块组2的组描述符
  9. ------------------------------------------------------------------------
  10. 000860 04 61 00 00 05 61 00 00 06 61 00 00 fd 1d f0 07
  11. 000870 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  12. 000880 01 80 00 00 02 80 00 00 03 80 00 00 00 1f f0 07
  13. 000890 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  14. 0008a0 04 a1 00 00 05 a1 00 00 06 a1 00 00 fd 1d f0 07
  15. 0008b0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  16. 0008c0 01 c0 00 00 02 c0 00 00 03 c0 00 00 00 1f f0 07
  17. 0008d0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  18. 0008e0 04 e1 00 00 05 e1 00 00 06 e1 00 00 fd 1d f0 07
  19. 0008f0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  20. 000900 01 00 01 00 02 00 01 00 03 00 01 00 00 1f f0 07
  21. 000910 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  22. 000fb0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  23. 000fc0 01 c0 07 00 02 c0 07 00 03 c0 07 00 ff 0e f0 07
  24. 000fd0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 块组62的组描述符
  25. -----------------------------------------------------------------------
  26. 000fe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  28. *                                                     没有块组63
  29. ----------------------------------------------------------------------
  30. 001000 04 20 00 00 04 60 00 00 04 a0 00 00 04 e0 00 00
     04 01 00 00 转换成可读的十进制是0x104=259，表示数据位图位于第259块block。inode位图位于260，和debugfs出来的信息是一样的（不算启动块）。0x1def=7663个空闲数据块....
 
    各位看官可以自己解析任何一个块组的相关信息，可以证明和debugfs出来的块组的信息是一致的。现在我们确定了，组描述符以数组的形式存储在K个快上，对于我们只有63个组块，每个组块需要32个字节，只需要2个1KB的block就足够了。这就是说，其实组描述符和超级块一样，其实是冗余的。也就是说，其他存储组描述符的两个block，信息和块组0中的组描述符的两个block是一样的。下面我来证明。
  
    块组25也有组描述符块，204802和204803两个块，记录了63个块组的组描述符信息。内容应该和前面的块组0的两个块一致。我已经取出了这两个block的内容，大家自己比较吧，结果是内容是一样的。

 

  1. Group 25: (Blocks 204801-212992)
  2.   备份 superblock at 204801, Group descriptors at 204802-204803
  3.   保留的GDT块位于 204804-205059
  4.   Block bitmap at 205060 (+259), Inode bitmap at 205061 (+260)
  5.   Inode表位于 205062-205315 (+261)
  6.   7677 free blocks, 2032 free inodes, 0 directories
  7.   可用块数: 205316-212992
  8.   可用inode数: 50801-52832

 

点击(此处)折叠或打开

  1. [email protected]:/mnt/bean# dd if=/dev/loop0 bs=1k skip=204802 count=2|od -tx1 -Ax > /tmp/dump_hex_
  2. 记录了2+0 的读入
  3. 记录了2+0 的写出
  4. 2048字节(2.0 kB)已复制，0.000160205 秒，12.8 MB/秒
  5. [email protected]:/mnt/bean# vi /tmp/dump_hex_
  8. 000000 04 01 00 00 05 01 00 00 06 01 00 00 ef 1d e5 07
  9. 000010 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  10. 000020 04 21 00 00 05 21 00 00 06 21 00 00 fd 1d f0 07
  11. 000030 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  12. 000040 01 40 00 00 02 40 00 00 03 40 00 00 00 1f f0 07
  13. 000050 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  14. 000060 04 61 00 00 05 61 00 00 06 61 00 00 fd 1d f0 07
  15. 000070 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  16. 000080 01 80 00 00 02 80 00 00 03 80 00 00 00 1f f0 07
  17. 000090 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  18. 0000a0 04 a1 00 00 05 a1 00 00 06 a1 00 00 fd 1d f0 07
  19. 0000b0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  20. ....
  22. 0007c0 01 c0 07 00 02 c0 07 00 03 c0 07 00 ff 0e f0 07
  23. 0007d0 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
  24. 0007e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  25. *
  26. 000800
    
    最后，最后的最后，解释以下，为什么每个块组中的块数blocks per group 是8192,因为，我们用1个块作为位图保存本块组 block的使用情况（bit为1表示对应的block被使用，bit为0表示对应的block空闲），1个block是1024字节，共有1024*8=8192个bit，所以，每个块组最多只能是81292个块。
 
    同样道理如果用户使用的是4094大小的块，那么，4096*8=32768个bit，所以每个块组会有32K个块。证据在下面。

  1. [email protected]:/mnt/bean# cd /home
  2. [email protected]:/home# umount /dev/loop0
  3. [email protected]:/home# cd /mnt/bean
  4. [email protected]:/mnt/bean# ll
  5. 总用量 8
  6. drwxr-xr-x 2 root root 4096 2012-07-06 22:32 ./
  7. drwxr-xr-x 4 root root 4096 2012-07-06 22:32 ../
  8. [email protected]:/mnt/bean# mke2fs -b 4096 /dev/loop0
  9. mke2fs 1.41.11 (14-Mar-2010)
  10. 文件系统标签=
  11. 操作系统:Linux
  12. 块大小=4096 (log=2)
  13. 分块大小=4096 (log=2)
  14. Stride=0 blocks, Stripe width=0 blocks
  15. 128000 inodes, 128000 blocks
  16. 6400 blocks (5.00%) reserved for the super user
  17. 第一个数据块=0
  18. Maximum filesystem blocks=134217728
  19. 4 block groups
  20. 32768 blocks per group, 32768 fragments per group
  21. 32000 inodes per group
  22. Superblock backups stored on blocks: 
  23.     32768, 98304
  25. 正在写入inode表: 完成 
  26. Writing superblocks and filesystem accounting information: 完成
  28. This filesystem will be automatically checked every 39 mounts or
  29. 180 days, whichever comes first. Use tune2fs -c or -i to override
参考文献：
1 深入理解linux内核架构
2深入理解linux









制作ext2根文件系统

2.构建文件系统(部分需要root权限) 2.1.mkdirrootfs(后面文件系统就挂载在这里)2.2.ddif=/dev/zeroof=rootfs.ext2bs=1kcount=512000(制作500MB大小的根文件系统，实际文件系统空间不能超出这个范围）2.3.losetup /dev/loop0rootfs.ext2&#... 查看详情

ext2文件系统

 很久以来，就想写一篇关于ext家族文件系统的文章，源于我刚工作的时候，曾经一不小心rm-rf，误删除了很多文件，当时真想有个数据恢复软件能帮我把数据回复了。当然学习数据恢复，首先要学习文件系统。最近工作原因... 查看详情

ext2文件系统

Linux系统编程(FileSystem)关于ext2文件系统什么是文件格式化就是在执行一个文件读取与访问的规则ext2文件系统的结构关于文件的函数getcwdchdirchmodreadlinkstat->structstatfilestat->filestat.st_...->mode,size,blksize(IOBlock的大小,1k,2k或者4k),bl... 查看详情

linux支持啥格式的硬盘？

linux支持什么格式的硬盘？它又使用什么文件系统格式？linux从硬件角度上基本支持所有的硬盘，软件上也支持大量的文件系统。1）ext2文件系统；　　ext2文件系统应该说是Linux正宗的文件系统，早期的Linux都是用ext2，但随着技术... 查看详情

ext2文件系统

对文件系统而言，文件仅是一系列可读写的数据块。文件系统并不需要了解数据块应该放到物理介质上什么位置。这些都是设备驱动的任务。无论何时，只要文件系统需要从包含它的块设备中读取信息或数据，它就将请求底层的... 查看详情

文件系统概述和ext2文件系统(代码片段)

文件系统概述和EXT2文件系统文件系统概述常用的文件系统有windows98前的FAT、windows2000后的NTFS、linux的Ext2/3/4、SGI的XFS文件系统等对于传统的文件系统而言，一个分区槽只能格式化为一个文件系统，但是目前由于LVM与软件磁盘阵列... 查看详情

linux分区类型ext2ext3ext4详解

一、EXT2与EXT3  Linux之前缺省情况下使用的文件系统为Ext2，ext2文件系统的确高效稳定。但是，随着Linux系统在关键业务中的应用，Linux文件系统的弱点也渐渐显露出来了:其中系统缺省使用的ext2文件系统是非日志文件系统。... 查看详情

像ext3，ext2，ext这样的文件系统是啥形式

】像ext3，ext2，ext这样的文件系统是啥形式【英文标题】：whatistheformoffilesystemlikeext3,ext2,ext像ext3，ext2，ext这样的文件系统是什么形式【发布时间】：2021-03-1201:26:06【问题描述】：我已经阅读了wikipedia、linfo.org中的文件系统以及... 查看详情

ext2文件系统学习——目录磁盘结构

创建镜像、mount等操作和上一篇一样，测试目录结构如下：一些文件系统信息如下：Blocksize:      1024Inodespergroup: 128Inodesize:      128Blockbitmapat 6Inodebitmapat7Ino 查看详情

ext2文件系统-mke2fs

...遍博文的重点其实将ext2整体的组织框架，我们知道了ext2文件系统由块组组成，每个块组里面的组织形式。我们甚至直接把超级块和组描述符里面的内容，用十六进制形式展现了出来。这篇博文主要讲述如何mke2fs生成合适需要的e... 查看详情

我所认识的ext2

前言：本文是笔者自己在学习文件系统中的一些体会，写出来和大家分享一下。本文首先是介绍了下文件系统的一些理论概念，然后分析了ext2文件系统的原理和部分源码。 文件系统是什么：       &n... 查看详情

ext2与ext3文件系统两者的差别

其实这两种文件系统的格式是完全相同的，只是ext3文件系统会在硬盘分区的最后面留出一块磁盘空间来存放日志（Journal）记录。在ext2格式的文件系统上，当要向硬盘中写入数据时，系统并不是立即将这些数据写到硬盘上，而是... 查看详情

第8章文件系统管理_文件系统和常用命令

1.文件系统（1）ext2文件系统　　ext2是ext文件系统的升级版本，RedHatLinux7.2版本以前的系统默认都是ext2文件系统。1993年发布，最大支持16TB的分区和最大2TB的文件（1TB=1024GB=1024*1024KB）（2）ext3文件系统　　ext3文件系统是ext2文件系... 查看详情

linux系统能够直接读取的分区类型是啥

以下是Linux支持的文件系统汇总1.minix：是Minix操作系统使用的文件系统,是Linux最先使用的文件系统。它有许多缺点:分区只能小于64MB,只支持短文件名,单一的时间戳,等等。在软盘和动态磁盘领域仍然有用。2.ext是对Minix的扩展。已... 查看详情

linux系统中系统文件有啥特点

Linux系统中系统文件有什么特点?第1个特点：内核相关文件在/boot目录下第2个特点：设备相关文件在/dev目录下都3个特点，系统和服务配置在/etc/下第4个特点，库文件在/lib下其它也没啥了。参考技术A般linux常用的文件系统有ext2、e... 查看详情

什么是区ext2区、ext3区、ext4？应当怎样分？

...区格式化再从新分区啊？求各位高手了！EXT2第二代扩展文件系统（英语：secondextendedfilesystem，缩写为ext2），是LINUX内核所用的文件系统。它开始由RémyCard设计，用以代替ext，于1993年1月加入linux核心支持之中。ext2的经典实现为LIN... 查看详情

ext3是对ext2文件系统的一个扩展高性能日志文件系统

嵌入式开发者所做的最重要的决定之一就是部署哪种文件系统。有些文件系统性能比较高有些文件系统空间利用率比较高，还有一些文件系统设备故障或者意外断电后恢复数据比较方便。linux文件系统概念分区分区是对物理设备... 查看详情

linux文件系统管理

参考技术A　　3.1Linux文件系统类型　　不同的操作系统使用不同类型的文件系统，为了与其他的操作系统兼容，以相互交换数据，　　通常，每种操作系统都支持多种类型的文件系统。　　Linux中保存数据的磁盘分区通常采用EXT2... 查看详情