我想要格式化 12 TB HDD（不是 SSD）与 EXT4，以便存储大型视频文件（每个文件大小至少为 1 GiB）。
我正在使用 x86-64（又名 x64 或 amd64）处理器。
当然可以-T largefile4选择mkfs.ext4，但是还有其他可以进行的优化吗？
我特别想知道：
- 我应该将块大小增加到最大值（64K，
-b 65536）吗？ - 或者我应该使用块簇，并将簇大小设置为最大值（256M，
-C 268 435 456） - 或者我应该两者都做？
就磁盘空间和性能优化而言，最佳参数是什么？
答案1
您链接的文件说（强调我的）：
目前，块的默认大小为 4KiB，这是大多数支持 MMU 的硬件上普遍支持的页面大小。这是幸运的，因为ext4 代码不准备处理块大小超过页面大小的情况。
在能够运行 Linux 的知名处理器架构中，只有 ARM、Alpha AXP、Itanium 或 PowerPC 能够使用超出通常 4 KiB 的页面大小。
虽然 AMD64/x86_64 处理器可以使用大页，但这并不完全相同 - 基本系统页面大小仍然是 4 KiB，大页只是允许将它们分配在更大的捆绑中，以提高大内存系统中的内存管理效率。这不会改变“ext4 块大小 <= 系统内存页大小”的基本要求。
使用 PowerPC 或 64 位 ARM 处理器，页面大小（系统内存管理的基本“块大小”）可以增加到 64 KiB，这使得 ext4 文件系统也可以扩展其内部操作。在 AMD64/x86_64 上，该选项不可用，因此块集群将是减少文件系统元数据所需的空间和工作的唯一可用方法。
我使用的系统的 ext4 文件系统扩展到 >10 TB 范围，并且对其运行文件系统检查并不是一种愉快的体验。诚然，这是一个旧系统，其文件系统在没有经过任何仔细调整的情况下不断扩展，远远超出了系统原始设计容量的限制。 （它也是一个视频服务器。）
但基于此，我想说 ext4 肯定需要特定的调整才能成功处理数十 TB 的文件系统。就像评论中的 Romeo Ninov 一样，我敦促您重新考虑其他文件系统类型（如果可能的话）：尽管 ext4能与大于 10 TB 的文件系统一起使用时，我认为低几十 TB 大约是当前通常的限制实际的与它有关。
但是，如果您基本上只写入一次文件系统的内容，然后将其保持为只读，那么您几乎永远不需要对其运行文件系统检查，这将避免一个重大痛点。
答案2
Ext4 可以相当好地处理高达 16TiB 的文件和高达 1PiB 的文件系统，并且在世界上一些最大的并行文件系统中经常以这些大小使用（请参阅https://en.wikipedia.org/wiki/Lustre_(文件系统)了解详情）。 1GiB 文件和 12 TiB HDD 应该不会有任何问题。
我的家庭文件服务器中有几个 10 TiB 驱动器，采用 ext4。启用范围和其他功能的默认 mke2fs 选项应该提供良好的性能。
至于largefile选项，如果您知道大多数文件将非常大。然而，总体节省的空间并不大，而且可能不值得。我最终也使用我的媒体服务器进行备份，这创建了大量的小文件。
答案3
扩展 TelcoM 的答案...如果您想在 x86[-64] 上使用 4Kb 以外的块大小，那么您将需要重新编译内核。这曾经是支持具有 32 位内核的大型文件系统的唯一方法。但随后出现了大文件支持和 64 位 inode。如今（除非您仍在 32 位上运行）您甚至不需要告诉 mount/fstab 文件系统使用 64 位。但互联网上仍然有很多过时的信息（例如当前的 aws 文档 -https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html）。
ext4 中的块簇为 32 位 inodes/4k 块大小提供了解决方法。
但这不仅不再相关 - 32 位 inode + 4K 块大小将块设备的总大小限制为 16Tb，而您只有 12 个。
使用不同大小的块（或块簇）是有原因的。 IIRC，Oracle 和 MySQL 都在内部使用 8k 块大小 - 并且在文件系统上匹配此大小可以显着提高吞吐量。
所以......不，你不需要做任何聪明的事情（除了在分区时使用 GPT 而不是 MBR）。