关于分区布局的简短问题。我使用 SSD 来存储 /、/boot、/usr 和 /home 分区。我想将 /var 移动到机械磁盘以尽量减少对 SSD 的写入。我主要关心的是最大限度地延长驱动器寿命，而不是最大限度地提高性能（尽管我显然不想让我的服务器瘫痪）。
我的机械磁盘由两个共享 LVM 的驱动器组成，第三个驱动器用于夜间 rsync 备份。我还放着一堆旧的 2.5 英寸硬盘。
我的问题是，我是否应该简单地在主数据存储上创建一个新的 LVM 卷“/var”，或者是否值得增加能耗（就最大化 LVMed 驱动器的使用寿命而言）来安装一个低容量 2.5 英寸磁盘仅用于 /var？
从更一般的层面上讲，我的问题是关于将操作系统挂载到与我的数据相同的物理卷上的权衡。感谢您的帮助！
答案1
1.3GB/天的数据量并不大。英特尔对英特尔 320 系列固态硬盘的评级为 5 年内每天 20GB 的 4k 随机写入量（英特尔 320 规格)。4k 随机写入代表了闪存写入/擦除周期的最坏情况，对于标准工作负载，您不太可能持续达到这一水平，因此您的实际寿命会更好一些。
其他 SSD 可能在此有所不同，但总的来说，如果您使用的是现代 SSD，我不会担心这种写入级别。
您还可以检查 SSD 报告的磨损程度，以更好地了解其使用寿命。我发布了这里关于如何使用英特尔固态硬盘 (SSD) 进行检查。其他控制器将报告不同的属性，但所有现代固态硬盘 (SSD) 都以某种方式报告相同的数据。
许多现代 SSD 控制器芯片组也进行压缩，这将进一步增加写入寿命，假设数据可压缩（/var 中的大多数内容，例如日志文件，都可以很好地压缩）
举例来说，以下是在基于 Sandforce 的 OCZ Vertex 2 上运行 smartctl 的一些输出：
9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 8298h+23m+00.940s
231 SSD_Life_Left 0x0013 087 087 010 Pre-fail Always - 0
233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 30272
234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 124672
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 124672
242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 3136
我把它放进这台机器还不到一年，这与通电时间数字（345 天）很吻合。这个驱动器在 345 天内已经完成了 124672GiB，或每天大约 361GiB。SSD 内部磨损计数器为 87% - 因此在运行近一年后，它磨损了约 13%。
这可能是非常可压缩的（RRD 数据，从空数据集开始，因此有很多高度可压缩的 RRD）。我的理解是属性 233 是写入 SSD 的“实际”数据量，而 234 / 241 是“未压缩”的。这意味着它实际上完成了 30272 GiB 的写入，大约是 87GiB/天。
（顺便说一句，这两个数字对我来说似乎有点高，但我的操作系统级监控报告这些驱动器的写入速度稳定在 4.5MiB/秒，非常接近 360GB/天，所以加起来没问题。Linux 内核和驱动器控制器以完全相同的方式出错的可能性很小）
这在一定程度上取决于您的 SSD 和您的特定工作负载，但我认为没有必要将 /var 从您的 SSD 上移走。
答案2
对于任何 ssd 来说，1.3gb/天都足够了（也许除了一些非常非常旧的）。以下是 ssd 寿命计算器的报告： http://www.ssdready.com/measure/?value=1.3&msr=Gb&submit=Estimate%21