主页 / unix / 问题 / 760131
Accepted
Vlastimil Burián
Asked: 2023-10-29 20:47:49 +0800 CST

对于大型 Ext4 驱动器，是否有一些普遍推荐的保留块数（针对根）？

  • 772

通过以下问题：

对于大型 Ext4 驱动器，是否有一些普遍推荐的保留块数（针对根）？

我具体指的是以下几点：

  • 让我们考虑一下（几乎）每个人现在都有一个相当大的根驱动器（分区）。

  • 让我们考虑一下带有 1.8TiB 根分区的 2TB 驱动器，这意味着除了第一个引导分区之外的整个驱动器都被使用。

  • 此外，让我们假设只有我可以访问这台计算机，并且我可以直接访问硬件和操作系统。

  • 作为补充，我在 GRUB 中设置了：GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=journal"，我没有找到的特定文档，请随意在此处添加。

为了将所有这些放入一个工作示例中，这是我笔记本电脑中的 NVMe 驱动器：

# fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 989573D5-37E7-437A-B680-9410F7234A94

Device          Start        End    Sectors  Size Type
/dev/nvme0n1p1   2048     194559     192512   94M EFI System
/dev/nvme0n1p2 194560 3907028991 3906834432  1.8T Linux filesystem

第二个分区/dev/nvme0n1p2是 Ext4 文件系统类型，以下是考虑它的完整值列表：

# tune2fs -l /dev/nvme0n1p2 
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          f1fc7345-be7a-4c6b-9559-fc6e2d445bfa
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:              122093568
Block count:              488354304
Reserved block count:     20068825
Free blocks:              388970513
Free inodes:              121209636
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      817
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 Jun 16 11:26:24 2018
Last mount time:          Thu Oct 26 09:14:38 2023
Last write time:          Thu Oct 26 09:14:38 2023
Mount count:              102
Maximum mount count:      -1
Last checked:             Tue Sep 26 03:05:31 2023
Check interval:           0 (<none>)
Lifetime writes:          43 TB
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
First orphan inode:       134214
Default directory hash:   half_md4
Directory Hash Seed:      48360d76-0cfb-4aed-892e-a8f3a30dd794
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x58d12a63

我想评估一下是否需要一些保留的根空间，如果需要，需要多少。我希望这个问题不要基于意见，所以如果您决定添加答案，请添加一些参考资料，谢谢。

root

1 个回答

  1. Best Answer

    因此，根本没有什么重要的理由存在。

    最简单的原因是，您希望根运行的服务将日志和/或数据保存到该卷，即使用户用数据淹没驱动器，也能继续工作。显然，这仅在以下情况下才有意义：

    1. 您所指的卷实际上由根运行的进程使用，并且
    2. 它也由那些不能通过在磁盘中填充文件来拒绝这些服务的操作的用户使用，并且
    3. 服务继续运行比非特权用户能够写入用户数据更重要。

    你的似乎是一个桌面系统，所以至少，我会说 3. 是有问题的，如果不是与你需要的完全相反的话。

    因此，我认为这是一个非常无力的论点，特别是因为现在许多服务一开始就不是以 root 身份运行的。

    然后，另一个论点（这里由 ext4 的“主要”开发人员提出）是，没有太多可用空间使得文件系统更难找到连续的块区域来用于新的或不断增长的文件。这导致了所谓的碎片化，这是旋转磁盘存储上的硬件性能问题（由于寻道时间较长），并且由于存储和读取碎片文件的方式更加复杂和重定向，因此仍然是一个开销问题。文件系统驱动程序需要使分散在存储各处的文件对于应用程序来说看起来是连续的，而这最终是以牺牲预取和缓存的能力为代价的；仍然是 SSD 的一个小问题。它还会增加元数据的大小。我对 ext4 的内部结构不够熟悉，无法告诉您对元数据的需求增加是否会减少可用空间，或者只是意味着在访问碎片文件时需要进行更多查找。

    https://listman.redhat.com/archives/ext3-users/2009-January/msg00026.html

    如果将保留块计数设置为零，则不会对性能产生太大影响，除非您长时间运行（创建和删除大量文件）而文件系统几乎已满（即超过 95%），此时您将遇到碎片问题

    […]

    如果您只是使用文件系统进行长期存档，其中文件不经常更改（即巨大的 mp3 或视频存储），那么这显然并不重要。

    所以，这实际上取决于您的用例。看到您的文件系统安装在/，它可能是您安装的所有软件所在的文件系统 - 大型软件更新正是这些大量删除和创建文件的时期。因此，保留足够的空间，以便平均而言，当创建的文件和删除的文件的大小平衡时，您可以自由地从存储的足够连续部分中进行选择，这是有意义的。

    那么，那会是多少呢？很难说。但是，假设一个大型更新过程可能进行 20 GB（10 GB 的新文件，之后删除 10 GB 的旧文件）的更改，这实际上似乎是一个合理的上限。因此，这对于预留空间来说似乎很有价值。

    您的文件系统大小为 1.86 TB，这意味着您的 NVMe 可能是消费者/专业消费者 1.92 TB 设备。目前每 TB 的运行价格为 45 至 80 欧元。我建议您仔细检查一下，考虑“优化”保留空间是否值得您的精神空间，无论是金钱上的。当然，78 GB 可能远远超出您的需要，但如果这相当于存储空间少于 6.60 欧元，您是否足够关心是否真正足够？

    • 2

相关问题