.thunderbird中的邮箱文件是否被视为数据库文件（重复随机写入）？如果我将 .thunderbird 留在普通的 BTRFS 分区上，碎片会有多严重？我希望人们能够分享他们在这个问题上的经验。
答案1
有几点想法：
- Thunderbird 默认使用的邮箱格式（仍然）是连续的 - 新邮件附加在末尾。所以，根本没有随机写访问！
- 消息元数据（每条消息在邮箱文件中的哪个位置开始？是否被删除？有任何标签吗？）存储在所谓的 MORK 数据库文件 (.msf) 中。这是一种糟糕的数据库格式（似乎每个人都同意）。更改其中的任何内容都需要重写大部分文件（这是半顺序的）。因此，也没有随机准时写入访问。
- 我不知道你收到了多少封电子邮件，但即使在糟糕的日子里，对我来说每分钟也少于 2 封。不是“频繁”，例如您的浏览器历史记录被频繁写入。 （现在实际上是一个数据库文件 – 例如，如果您使用 Firefox，则为 SQLite）
- 即使在实际的随机访问修改上，COW 也可以与不进行 COW 一样有效。存储介质实际上无法一次更改一个字节。他们必须在物理上写回修改后的块，包括计算前向纠错冗余。
- 因此，对于基于闪存的存储 (SSD)，存储设备大小的块 COW 行为没有任何缺点，因为文件碎片化不涉及寻道时间。 （事实上，SSD总是出于磨损均衡的原因，在内部对块执行 COW。）
- 当然，对于具有寻道时间 (HDD) 的设备，在顺序读取文件时，碎片文件会影响访问时间。如果这对您很重要，您可能有很多电子邮件（像我一样，我最近统计过，我的 Thunderbirds 有超过 50,000 封电子邮件），并且您可能需要考虑 Thunderbird 的替代品（就像我经常做的那样，即使我正在使用我不再使用 Thunderbird 在本地进行全文搜索 我的虚拟服务器的 CPU、RAM 和存储性能远低于我的工作站，它保留了用于服务器端搜索的全文索引，并且速度快了 20 倍以上。作为雷鸟，所以我（尴尬地）使用“在服务器上搜索”功能让我的 IMAP 服务器搜索电子邮件，而不是雷鸟在本地搜索）。
总而言之：除了用桌面电子邮件客户端处理的几封电子邮件之外，去担心其他事情吧！现代文件系统确实能够很好地满足这一点。
（丑陋的事实是，Mozilla 在过去十年中一直在致力于取代存储消息和消息信息的低效方式。他们目前选择的一些方法，但似乎需要一段时间才能做好生产准备，都很棒，比如为当前的 Mork 使用适当的数据库文件，其他的则不太好，例如使用 Maildir 格式，如果您需要执行任何跨电子邮件操作，则这种格式并不是很有效，这实际上是我认为雷鸟使用“正常”文件格式来解决此类问题很复杂，我也认为这是一个根本性的缺点，我们有四个缺点。现在 Thunderbird 中的聊天信使，其中一些甚至不适用于仍然存在的聊天网络，相反，我们没有一种强大且相当有效的方式来存储电子邮件 - 在电子邮件客户端中。）