我有一个应用程序，它使用大量空间作为缓存数据。可用的缓存越多，应用程序的性能就越好。我们说的是数百到数千 TB。如果块出现问题，应用程序可以即时重新生成数据，所以我的主要目标是最大限度地增加文件系统上可用于缓存数据的大小，并尽量减少文件系统开销。
我愿意牺牲所有的可靠性和灵活性以及“通用性”要求。最重要的是，我确切地知道在任何给定卷上我将拥有多少个缓存数据文件，因为应用程序写入的缓存文件大小是固定的（在我的情况下是~100GB）。如果某个块偶尔出现问题，我希望能够用新文件覆盖一个文件，因此最好有一些备用的 inode，但如果需要，也可以重新格式化整个卷。这些文件都存储在文件系统的 1 个目录深处。例如，目录名可以限制为一个字母，我也不需要目录（所有文件也可以存储在卷根的顶层）。文件名都是固定大小（哈希加时间戳）。一旦写入缓存数据，文件将只能被读取，卷可以以只读方式挂载。缓存有效期很长（数年）。应用程序也会验证缓存的完整性，因此我不需要任何文件系统完整性功能，如校验和、日志记录等。
因此，假设我知道确切的、固定的文件大小并且没有可靠性问题，我应该使用什么文件系统以及如何调整它以尽可能地消除开销？