鉴于我想创建自己的数据库存储，文件的大小应该是多少以避免碎片和文件系统开销，尤其是在“新”SSD的情况下？
例如，很多64千字节的文件是否可以？或者是以惊人的速度使用文件（inode）条目？
使用大文件并仅在64千字节范围内访问它会更好吗？
（我使用64 kbyte作为例子。也许4kbyte是神奇的尺寸？还告诉我，如果我在漫无边际，或者我是否表达了自己的观点。）
答案 0 :(得分：3)
好问题。
现代SSD中的闪存通常（！）结构如下：页面大小为2K或4K，可写入和256K擦除块。如果不删除页面，则无法覆盖该页面。但擦除操作仅适用于完全擦除块。但是，每次擦除操作都需要很长时间（与其他IO操作相比）并且会慢慢磨损SSD。
SSD控制器的一个名为FTL（闪存转换层）的组件用于在闪存语义上提供类似HDD的块设备的错觉。 SSD可以像硬盘驱动器一样使用，但为了充分利用它（并且长时间使用），结合存储知识的软件IO设计效果最佳。
然而，SSD控制器逻辑通常是未知的。因此它可能因SSD而异，但这里有一些经验法则：
如果可能，我会将我的IO模式和文件大小与完全擦除块（或其倍数）对齐。因此，写入256K的文件使用完整的擦除块而没有任何内部碎片。像64K这样的较小文件只会使用其中的一部分。将数据写入块的其余部分可能会导致读 - 修改 - 写周期。这意味着读取，修改完整块然后将其写入另一个位置。很贵。
当SSD为空（因为控制器有足够的未使用的块）时，这不是问题，但如果SSD已满且使用频繁，则可能会出现问题。或者，如果IO模式通常是非常小的写入并且SSD变得碎片化。因此，FTL很难找到连续的免费闪存页面。
作为旁注：系统管理员应该将文件系统与SSD擦除块边界对齐，这非常重要。
答案 1 :(得分：2)
由于系统对任何现代磁盘的视图与物理设备上的实际位置不匹配，因此情况更糟。现代磁盘，包括固态硬盘和旋转磁盘，都可以将部门放在他们想要的地方。
由于SSD具有磨损均衡，因此27可能不会接近第28区，并且，即使它们一起开始“接近”，也可能在写完之后不会接近。此外，当然，由于没有寻道时间，使用SSD“关闭”的概念是一种奇怪的概念。
如果设计与较少的大文件一样简单，我会回避任何有负载和文件加载的设计。另一方面，如果您发现自己在编写单个大文件中的块映射时自己编写了相应的文件系统，那么除非您的问题具有非常具体的功能，否则最好是利用所有时间和思想已经进入现有的文件系统设计。