网上有很多资源讨论在 RAID 配置中使用 SSD 驱动器——但是这些资源大多可以追溯到几年前，而且 SSD 生态系统发展非常迅速——正如我们期待英特尔在今年晚些时候发布“傲腾”产品一样这将改变一切......再次。
我将通过肯定消费级 SSD（例如 Intel 535）和数据中心级 SSD（例如 Intel DC S3700）之间存在质的差异来开始我的问题。
我的主要关注点与TRIMRAID 方案中的支持有关。据我了解，尽管 SSD 被引入消费级计算机已有 6 年多，而 NVMe 已商用 4 年——现代 RAID 控制器仍然不支持向TRIM连接的 SSD发出命令——英特尔的 RAID 控制器除外在 RAID-0 模式下。
我很惊讶TRIM在 RAID-1 模式中不提供支持，考虑到驱动器相互镜像的方式，这似乎很简单。但我离题了。
我注意到，如果您想要磁盘（HDD 和 SSD）的容错性，您可以在 RAID 配置中使用它们 - 但由于 SSD 没有 TRIM，这意味着它们会遭受写入放大，从而导致额外磨损，从而反过来会导致 SSD 过早失效——这是一个不幸的讽刺：一个旨在防止驱动器故障的系统可能最终会直接导致它。
所以：
TRIM现代（2015-2016 时代）SSD是否需要支持？
1.1. TRIMSATA、SATA-Express 和基于 NVMe 的 SSD对支持的需求有什么不同吗？
通常，驱动器被宣传为具有改进的内置垃圾收集功能；这是否排除了需要TRIM？他们的 GC 过程如何在 RAID 环境中工作？
1.1. 例如，请参阅 2010 年的此 QA，它描述了由于 not-TRIMming ( https://superuser.com/questions/188985/how-badly-do-ssds-degrade-without-trim )而导致的非常糟糕的性能下降- …
我们正在研究在一组 SSD 磁盘上使用 BtrFS，我被要求验证 BtrFS 确实在删除文件时执行 TRIM 操作。到目前为止，我一直无法验证 TRIM 命令是否已发送到磁盘。
我知道 BtrFS 不被视为生产就绪，但我们喜欢最前沿的技术，因此我正在测试它。服务器是 Ubuntu 11.04 服务器 64 位版本（mkfs.btrfs 版本 0.19）。我已经安装了 Linux 3.0.0 内核，因为BtrFS 更改日志指出在 Ubuntu 11.04 (2.6.38) 附带的内核中批量 TRIM 不可用。
这是我的测试方法（最初采用http://andyduffell.com/techblog/?p=852，经过修改以与 BtrFS 一起使用）：
for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done./sectors.pl |grep + | tee sectors-$(date +%s)fdisk /dev/sdamkfs.btrfs /dev/sda1sudo mount -t btrfs -o ssd /dev/sda1 /mnt我们在 Linux（当前为 2.6.37）上使用 RAID1+0 和 md 创建一个 md 设备，然后使用 LVM 在设备之上提供卷管理，然后使用 ext4 作为我们在 LVM 卷组上的文件系统。
使用 SSD 作为驱动器，我们希望看到 TRIM 命令通过层（ext4 -> LVM -> md -> SSD）传播到设备。
看起来最近的 2.6.3x 内核添加了许多与 SSD 相关的新 TRIM 支持，包括对 Device Mapper 场景的更多覆盖，但我们似乎仍然无法使其正确级联。
这还有可能吗？如果是这样，如何？如果没有，是否有任何进展？
从这些先前提出的问题中剥离出来
我们有一个 HP 3PAR StoreServ 7400，其中 170 个虚拟机分布在 38 台主机上。
这是我理解的问题：（另外我被告知一些信息，我不确定它是否真实，我已经阅读了 HP 3PAR StoreServ 7400 白皮书并且真的找不到任何可以备份我的存储人员的东西告诉我。所以在下面如果有人注意到任何不真实的地方，请告诉我。）
3 PAR 分为 3 个部分，
第 1 层：SSD 用于缓存和快速访问常用文件。
第 2 层：和第 3 层：某种旋转盘，什么以及为什么有额外的 2 层我不确定，但我的假设是第 2 层用于不是最常访问但访问位的数据，第 3 层用于其余的存储。
在 SSD 部分中，当数据写入 SSD 块然后删除该块时，我在许多文章中读到过，直到将新数据写入该块时，该块才会归零，因此，当块内的数据被删除时，存储映射的表info 得到更新，然后当新数据写入同一个块时，该块首先需要归零，然后才能写入。如果驱动器没有周期性地调整，SSD 中的这个过程会导致较低的 w/r 速度。
3PAR LUN 是精简配置的，VM 是 Eager 厚配置的。
根据我的存储专家的说法，3PAR 有一个内置的特殊功能，可以根据需要将未使用的 SSD 存储提供给其他 VM，这是没有意义的。
事实核查：
厚置备的 VM 是一个 VMDK 文件，创建 VM 时，您指定 VM 的大小，这将创建一个 VMDK 文件。在我看来，这告诉我，如果 VM 被定期访问，那么整个 VMDK …
在较旧的操作系统（CentOS 5.5）上使用现代内核（当前为 2.6.37），以便我们可以在我们的 SSD（Crucial C300s）上使用 TRIM（丢弃）。
最新的 hdparm (9.37) 一致认为 C300 支持 TRIM：
./hdparm -I /dev/sdc | grep TRIM
* Data Set Management TRIM supported (limit unknown)
* Deterministic read data after TRIM
但是当我尝试使用丢弃选项挂载 /dev/sdc 时，内核似乎不同意：
EXT4-fs warning (device sdc): ext4_issue_discard:2619: discard not supported, disabling
当我输入这个时，我们正在尝试其他 Linux 版本，但无论如何知道发生了什么会很好。
这是 CentOS 5.5 的其他一些古老组件误导内核的表现吗？或者 hdparm 是否使用与内核不同的机制来确定是否支持 TRIM？
问题
我想在 Linux 上的 SSD 磁盘内的交换分区上启用后台TRIM 操作。根据几篇文章，例如这篇文章，内核会检测此配置并自动执行丢弃操作，但在我的测试中，尽管使用“丢弃”挂载选项来强制执行此行为，但它似乎不起作用。
设想
背景
这些是我用来检查后台 TRIM 是否在交换分区上工作的步骤：
TRIM 支持：检查 SSD 磁盘是否支持 TRIM 命令并且内核将设备标记为非旋转：
# hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 1 block)
* Deterministic read data after TRIM
# cat /sys/block/sda/queue/rotational
0
交换填充：挂载分区，清理所有 VM 缓存并配置 Linux 以积极交换，将 vm.swappiness 设置为 100。然后，运行一个脚本来分配所有可用内存并强制内核开始交换：
# swapon [--discard] /dev/sda2
# …在文件系统上实现 fstrim 的方法之一，它使 cron.daily 任务运行fstrim /. -o discard很多人更喜欢（挂载选项），因为后者会使写入速度变慢，尤其是删除大量小文件时。
我的问题是，当我做这样的 cron 工作时，如果这被重新启动/停止或更糟糕的断电中断会发生什么？SSD 一开始就不喜欢功率损耗（甚至有一个 SMART 参数来计算它们），我可以想象 fstrim 期间的功率损耗更糟。
我们即将订购带有 H700 的戴尔 R610。我们曾考虑在 RAID 1 中使用 2 个三星 850 Pro 512Gb 驱动器。
问题是 Perc H700 是否支持硬件 RAID 1 中的 TRIM？我从谷歌搜索中找到的答案似乎表明没有，但这似乎也是一个快速发展的领域，从那时起就有了固件更新。
哦，看来非戴尔认证的驱动器将不再被阻止
或者，如果使用最新固件的 H700 上的 RAID 1 没有硬件支持的 TRIM，那么获得基于 Sandforce 控制器的内置 TRIM 的 SSD 会更好吗？例如金士顿 HyperX 似乎在耐力测试中表现相当不错
三星 850 的统计数据比 HyperX 驱动器更好，但我相信如果不向它们发出 TRIM 命令，性能会下降......
因此，PERC H700 是否支持 TRIM，如果不支持，那么是否有另一个硬件 RAID 控制器支持，如果不是，则是使用 Sandforce 控制的 SSD 的最佳选择？
谢谢，贾斯
我已经在繁忙的 Ubuntu 服务器上使用一对 Intel 320 RAID 1 大约 4 个月了。虽然磁盘使用率从未达到容量的 50%，但我感觉服务器的响应速度变慢了，所以我想知道是否需要运行修剪，如果需要，该怎么做？（升级到Ubuntu 10.10后Linux内核为3.0）
谢谢
在 VMware ESXi 5.5 中使用最近 (>= 2014) 发行版创建新的 Linux 虚拟机时，是否应该使用discard选项挂载其文件系统？
我假设 VM 的管理员不一定知道实际的底层存储是什么，并且 VM 使用的是推荐的“虚拟控制器”，我希望/怀疑如果 VM 发出TRIM命令，它们可能对瘦有用虚拟磁盘（即使它们位于非 SSD 存储上）或 SSD 存储上的厚虚拟磁盘。
discard当在 ESXi VM 中使用时，挂载选项是否真的起作用（例如，即使虚拟控制器是 SCSI 控制器而不是 SATA 控制器）？
当 VM 使用此类discard选项时，vSphere >= 5.5 是否会执行任何操作？