ext4：如何考虑文件系统空间？

16

我最近格式化了1.5 TB驱动器，目的是用ext4替换ntfs。

然后我发现我保存的文件不适合新分区。

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

1K块的差异意味着减少了22 GiB的可用空间。

我已经执行了

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

毫不奇怪，它没有任何作用，因为这不会影响那些不存在的块。

尽管如此，fdisk报告ext4分区覆盖了整个磁盘。

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

因此，例如resize2fs报告说“没事！”

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

缺少的空间在使用什么？

filesystems disk-usage ext4

— 杂项
source

21

让我们来看看。设备大小为1,465,138,583½kB = 1,500,301,909,504B。文件系统由366,284,288个4096 B的块组成，每个块为1,500,300,443,648B。我不知道剩余的1,465,856 B（1.4 MB）用于（超级块的其他副本）？我知道引导加载程序的开头有几kB的空间。）

该文件系统包含91,578,368个索引节点（每个256字节），占用23,444,062,208 B（约22 GB，提示，提示）。那么文件内容就有1,442,146,364 kB = 1,476,757,876,736B。这占23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944B。剩余大小为98,504,704 B = 24,029个块，这在正确的范围内是日志大小。

如您所见，一切都考虑在内。（好的，几乎所有内容，但是我们谈论的是兆字节，而不是千兆字节。）

— 吉勒斯“别再邪恶了”
source

1

谢谢，当然可以。（您呈现它的方式，也很明显–我应该多考虑一下。）因此，我使用“ mkfs.ext4 -m 0 -O sparse_super -T largefile4”重新创建了该分区，因为它只能容纳数千个文件，现在可用357728个inode与1464880364个块。

— 杂项

13

首先，您看到的可用空间上的差异完全不表示已“浪费”了空间。它不会浪费，因为它对于文件系统的运行至关重要。在没有很大的“而是”指定文件系统之间的所有设计和结构差异以及每个实现的细节（例如，每个驱动程序如何向VFS层报告可用空间）的情况下，您不应以这种方式比较Ext4和NTFS。

将该分区想象为一个巨大的空间，您可以在其中放置任何数据。如果只有一个大小等于分区的数据，则可以只在分区的开头开始写入，然后使用它。但是你没有。相反，您可能有数千个小文件，并且所有这些文件都以不同的方式分组，并且每个文件都与许多其他小数据（名称，日期/时间和权限）相关联，等等。您必须组织分区，以便您可以快速有效地访问所有这些数据。另外，您还必须考虑如何有效地写入新数据和丢弃旧数据。您需要数据结构。

并且有很多数据结构。其中一些非常愚蠢，其他一些则使您可以更快地检索数据，但代价是写入速度较慢，其他一些则可以使读取速度更快，但代价却是读取，某些仍然在读取和写入方面都非常出色，但需要较长的暂停时间和重新安排数据时的空闲开销等。

您当然想要一个系统：

在上面写信息的速度非常快；
从中检索信息的速度非常快；
善于组织和管理其中存储的信息；
充分利用文件系统的存储空间（分区）；
具有抵御硬件问题的能力，因此您仍然可以从部分系统故障中获得大部分或全部信息；
具有抵御软件问题的能力，因此应用程序中的错误或已安装的恶意应用程序不会永久破坏您的数据；
可以抵御人为错误，因此在您意外命令系统删除不应该删除的内容（也称为垃圾箱/回收站）时，它会原谅您。

高性能文件系统允许非常快速的读写操作，但会占用一些空间。文件系统中使用的某些最快的数据结构（例如哈希表和B树）非常复杂，并且它们保留比实际使用更多的空间，以允许非常快速的访问。

Ext4具有其他重要属性。文件系统中没有单个故障点。有很多关键数据的副本散布在整个分区中，而其他一些文件系统（对于NTFS，我不能说）可能会使所有数据变得不可读，如果在正确的位置发生了故障。同样，Ext4在文件系统创建阶段就为您的数据保留了大量空间，而NTFS随数据而增长。

— 朱利亚诺
source

1

谢谢，最后一部分至关重要。我不知道ext4在创建时（相对）在ntfs运行期间做了很多工作。

— 杂项

1

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

此消息表明磁盘使用GPT样式的分区，并且此fdisk工具仅了解旧的MBR样式。

为了防止在将GPT分区的磁盘插入较旧的非GPT感知的系统时意外重新格式化，GPT分区方案包括“保护性MBR”：一个完全伪造的分区表，该表基本上告诉“该磁盘已被您使用的分区类型完全使用对任何仅了解MBR分区的操作系统或工具“一无所知”。

要准确显示您的分区表，请/dev/sdb使用：

parted /dev/sdb print

— 电信
source