linux – 使用SSD上的BtrFS验证TRIM支持

linux – 使用SSD上的BtrFS验证TRIM支持,第1张

概述我们正在研究在SSD磁盘阵列上使用BtrFS,并且我被要求验证BtrFS在删除文件时确实执行TRIM *** 作.到目前为止,我无法验证TRIM命令是否已发送到磁盘. 我知道BtrFS不被认为是生产准备,但我们喜欢前沿,因此我正在测试它.服务器是Ubuntu 11.04服务器64位版本(mkfs.btrfs版本0.19).我已经安装了Linux 3.0.0内核,因为BtrFS changelog声明批量T 我们正在研究在SSD磁盘阵列上使用BtrFS,并且我被要求验证BtrFS在删除文件时确实执行TRIM *** 作.到目前为止,我无法验证TRIM命令是否已发送到磁盘.

我知道BtrFS不被认为是生产准备,但我们喜欢前沿,因此我正在测试它.服务器是Ubuntu 11.04服务器64位版本(mkfs.btrfs版本0.19).我已经安装了Linux 3.0.0内核,因为BtrFS changelog声明批量TRIM在Ubuntu 11.04(2.6.38)附带的内核中不可用.

这是我的测试方法(最初从http://andyduffell.com/techblog/?p=852开始采用,修改后与BtrFS一起使用):

>在开始之前手动TRIM磁盘:for {in {0..10};让A =“$i * 65536”; hdparm –trim-sector-ranges $A:65535 –please-destroy-my-drive / dev / sda; DONE
>验证驱动器是TRIM的:./ sectors.pl | grep |发球区 – $(日期%s)
>对驱动器进行分区:fdisk / dev / sda
>制作文件系统:mkfs.btrfs / dev / sda1
>装载:sudo mount -t btrfs -o ssd / dev / sda1 / mnt
>创建一个文件:dd if = / dev / urandom of = / mnt / testfile bs = 1k count = 50000 oflag = direct
>验证文件是否在磁盘上:./ sectors.pl |发球区 – $(日期%s)
>删除测试文件:rm / mnt / testfile
>看到测试文件是从磁盘TRIM进行的:./ sectors.pl |发球区 – $(日期%s)
>验证TRIM’d块:区分两个最近的sector- *文件

此时,预删除和删除后验证仍显示正在使用的相同磁盘块.我应该看到使用块数量的减少.删除测试文件后等待一小时(如果需要一段时间才能发出TRIM命令)仍然显示正在使用的相同块.

我也尝试使用-o ssd安装,丢弃选项,但这似乎没有任何帮助.

从上面的fdisk创建的分区(我保持分区小,以便验证更快):

root@ubuntu:~# fdisk -l -u /dev/sdadisk /dev/sda: 512.1 GB,512110190592 bytes255 heads,63 sectors/track,62260 cylinders,total 1000215216 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesdisk IDentifIEr: 0x6bb7542b   Device Boot      Start         End      Blocks   ID  System/dev/sda1              63      546209      273073+  83  linux

我的sector.pl脚本(我知道这是低效的,但它完成了工作):

#!/usr/bin/perl -wuse strict;my $device = '/dev/sda';my $start = 0;my $limit = 655360;foreach ($start..$limit) {    printf "\n%6d ",$_ if !($_ % 50);    my @sector = `/sbin/hdparm --read-sector $_ $device`;    my $status = '.';    foreach my $line (@sector) {            chomp $line;            next if $line eq '';            next if $line =~ /$device/;            next if $line =~ /^reading sector/;            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {                    $status = '+';            }    }    print $status;}print "\n";

我的测试方法有缺陷吗?我在这里错过了什么吗?

谢谢您的帮助.

解决方法 因此,经过多天的研究,我能够证明BtrFS确实使用了TRIM.我无法在将要部署这些SSD的服务器上成功运行TRIM.但是,当使用插入笔记本电脑的相同驱动器进行测试时,测试会成功.

用于所有这些测试的硬件:

> Crucial m4 SSD 512GB
> HP DL160se G6
> LSI LSISAS9200-8e HBA
>通用SAS机箱
>戴尔XPS m1210笔记本电脑

在许多尝试在服务器上验证BtrFS失败后,我决定使用旧笔记本电脑尝试相同的测试(删除RAID卡层).在笔记本电脑上使用Ext4和BtrFS进行此测试的初始尝试失败(数据未TRIM).

然后我将SSD驱动器固件从版本0001(开箱即用)升级到版本0009.使用Ext4和BtrFS重复测试,两个文件系统都成功地对数据进行了TRIM.

为了确保TRIM命令有时间运行,我做了一个rm / mnt / testfile&&同步&&在执行验证之前休眠120.

如果你正在尝试同样的测试,有一点需要注意:SSD有他们 *** 作的擦除块(我不知道Crucial m4擦除块的大小).当文件系统将TRIM命令发送到驱动器时​​,驱动器将只擦除一个完整的块;如果为块的一部分指定了TRIM命令,则由于擦除块内的剩余有效数据,该块将不会被TRIM.

那么为了演示我正在谈论的内容(上面的sectors.pl脚本的输出).这与SSD上的测试文件有关.期间是仅包含零的扇区.加号有一个或多个非零字节.

驱动器上的测试文件:

24600 .......................................+++++++++++24650 ++++++++++++++++++++++++++++++++++++++++++++++++++24700 ++++++++++++++++++++++++++++++++++++++++++++++++++    -- cut --34750 ++++++++++++++++++++++++++++++++++++++++++++++++++34800 ++++++++++++++++++++++++++++++++++++++++++++++++++34850 +++++++++++++++++++++++++++++.....................

从驱动器删除测试文件(在同步&& sleep 120之后):

24600 .......................................+..........24650 ..................................................24700 ..................................................    -- cut --34750 ..................................................34800 ..................................................34850 ......................+++++++.....................

看来该文件的第一个和最后一个扇区位于与文件其余部分不同的擦除块内.因此,有些部门没有受到影响.

一个外卖形式:一些Ext4 TRIM测试指令要求用户仅验证第一个扇区是否从文件中TRIM.测试人员应该查看测试文件的更大部分,以真正了解TRIM是否成功.

现在要弄清楚为什么手动发出通过RAID卡发送到SSD的TRIM命令工作但自动TRIM命令不…

总结

以上是内存溢出为你收集整理的linux – 使用SSD上的BtrFS验证TRIM支持全部内容,希望文章能够帮你解决linux – 使用SSD上的BtrFS验证TRIM支持所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/1045476.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-24
下一篇 2022-05-24

发表评论

登录后才能评论

评论列表(0条)

保存