我知道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创建的分区(我保持分区小,以便验证更快)：
@H_404_23@root@ubuntu:~# fdisk -l -u /dev/sda Disk /dev/sda: 512.1 GB,512110190592 bytes 255 heads,63 sectors/track,62260 cylinders,total 1000215216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6bb7542b Device Boot Start End Blocks Id System /dev/sda1 63 546209 273073+ 83 Linux我的sector.pl脚本(我知道这是低效的,但它完成了工作)：
@H_404_23@#!/usr/bin/perl -w use 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";我的测试方法有缺陷吗？我在这里错过了什么吗？
谢谢您的帮助.
解决方法
用于所有这些测试的硬件：
> 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上的测试文件有关.期间是仅包含零的扇区.加号有一个或多个非零字节.
驱动器上的测试文件：
@H_404_23@24600 .......................................+++++++++++ 24650 ++++++++++++++++++++++++++++++++++++++++++++++++++ 24700 ++++++++++++++++++++++++++++++++++++++++++++++++++ -- cut -- 34750 ++++++++++++++++++++++++++++++++++++++++++++++++++ 34800 ++++++++++++++++++++++++++++++++++++++++++++++++++ 34850 +++++++++++++++++++++++++++++.....................从驱动器删除测试文件(在同步&& sleep 120之后)：
@H_404_23@24600 .......................................+.......... 24650 .................................................. 24700 .................................................. -- cut -- 34750 .................................................. 34800 .................................................. 34850 ......................+++++++.....................看来该文件的第一个和最后一个扇区位于与文件其余部分不同的擦除块内.因此,有些部门没有受到影响.
一个外卖形式：一些Ext4 TRIM测试指令要求用户仅验证第一个扇区是否从文件中TRIM.测试人员应该查看测试文件的更大部分,以真正了解TRIM是否成功.
现在要弄清楚为什么手动发出通过RAID卡发送到SSD的TRIM命令工作但自动TRIM命令不…
