我正在设置一个运行Ubuntu精确的服务器,并试图验证SSD是否正常工作。
fstrim正在失败:
~ sudo fstrim -v /
fstrim: /: FITRIM ioctl failed: Operation not supported
因此,我在hdparm中尝试了wiper.sh:
wiper-3.5 sudo ./wiper.sh --verbose --commit /dev/sda1
wiper.sh: Linux SATA SSD TRIM utility, version 3.5, by Mark Lord.
rootdev=/dev/sda1
fsmode2
我有两个LUKS容器,一个带有默认的OpenSUSE安装程序设置,另一个带有-h sha512 -s 512 -i 5000和分离头。在它们的顶部都有LVM --一个只有一个OS卷(即btrfs ),另一个(分离)有3个卷-交换、ssd缓存和btrfs数据。问题是,OS卷上的btrfs比数据卷的性能要好得多。在没有LVM的LUKS上,操作系统的执行或多或少类似于原始btrfs,而有数据的则实现了类似于.三星SSD PRO 50 on /S序贯.(它比WD Green HDD慢)我计划用这个卷来处理VM,但是它非常慢,Win10的引导速度大约只有一分钟,而在操作系统分区上却只有几秒钟。
OS卷是
这篇文章 on forensicfocus.com说,下面是关于TRIM后面的确定性阅读(强调我的):
因此,支持DRAT (而不是DZAT )的SSD驱动器返回的数据可以是所有的零或其他数据字,也可以是存储在逻辑页中的original预剪裁数据。
这个句子使它听起来像是修剪过的数据可以在一些SSD上恢复,只需向SSD控制器请求就可以了。
hdparm告诉我,我的SSD (SanDisk SSD + 1000 me )启用了DRAT:
Data Set Management TRIM supported (limit 8 blocks)
Deterministic read data afte