Назад | Перейти на главную страницу

Проверьте поддержку TRIM с помощью BtrFS на SSD

Мы изучаем возможность использования BtrFS на массиве SSD-дисков, и меня попросили проверить, действительно ли BtrFS выполняет операции TRIM при удалении файла. Пока мне не удалось проверить, отправлена ли команда TRIM на диски.

Я знаю, что BtrFS не считается готовым к производству, но нам нравится передовой край, поэтому я тестирую его. Сервер представляет собой 64-битную версию сервера Ubuntu 11.04 (mkfs.btrfs версии 0.19). Я установил ядро Linux 3.0.0 как Журнал изменений BtrFS заявляет, что массовая TRIM недоступна в ядре, поставляемом с Ubuntu 11.04 (2.6.38).

Вот моя методология тестирования (изначально заимствованная из 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/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 | tee sectors-$(date +%s)
Удалите тестовый файл: rm /mnt/testfile
Убедитесь, что тестовый файл обрезан с диска: ./sectors.pl | tee sectors-$(date +%s)
Проверьте блоки TRIM'd: diff два последних sectors-* файлы

На этом этапе проверки перед удалением и после удаления по-прежнему показывают те же используемые дисковые блоки. Вместо этого я должен увидеть сокращение количества используемых блоков. Ожидание часа (в случае, если для выполнения команды TRIM требуется некоторое время) после удаления тестового файла все еще отображаются те же используемые блоки.

Я также пробовал монтировать с помощью -o ssd,discard варианты, но это, похоже, совсем не помогает.

Раздел, созданный из fdisk выше (я оставляю раздел маленьким, чтобы проверка прошла быстрее):

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

Мой sectors.pl скрипт (я знаю, что это неэффективно, но он выполняет свою работу):

#!/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";

Есть ли недостатки в моей методике тестирования? Я что-то упустил?

Спасибо за помощь.

Судя по тому, что я читал, в вашей методологии может быть изъян.

Вы предполагаете, что TRIM приведет к обнулению вашего SSD блоков, которые были удалены. Однако часто это не так.

Это только в том случае, если SSD реализует TRIM, чтобы обнулять отброшенные блоки. Вы можете проверить, знает ли устройство достаточно информации, чтобы сообщить о discard_zeroes_data:

кошка / система / блок / SDA / очередь / discard_zeroes_data

Кроме того, даже если SSD обнуляет, может потребоваться некоторое время - задолго до завершения сброса - для SSD, чтобы фактически обнулить блоки (это верно для некоторых SSD меньшего качества).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

Кстати, я искал надежный способ проверить TRIM и еще не нашел его. Я хотел бы знать, если кто-нибудь найдет способ.

Итак, после многих дней работы над этим я смог продемонстрировать, что BtrFS действительно использует TRIM. Мне не удалось успешно запустить TRIM на сервере, на котором мы будем развертывать эти SSD. Однако при тестировании с использованием того же диска, подключенного к ноутбуку, тесты проходят успешно.

Аппаратное обеспечение, используемое для всего этого тестирования:

SSD-накопитель Crucial m4 512 ГБ
HP DL160se G6
LSI LSISAS9200-8e HBA
стандартный корпус SAS
Ноутбук Dell XPS m1210

После многих неудачных попыток проверки BtrFS на сервере я решил попробовать тот же тест на старом ноутбуке (удалите слой карты RAID). Первоначальные попытки этого теста с использованием как Ext4, так и BtrFS на ноутбуке терпят неудачу (данные не TRIM'd).

Затем я обновил прошивку SSD-накопителя с версии 0001 (поставляемой из коробки) до версии 0009. Тесты были повторены с Ext4 и BtrFS, и обе файловые системы успешно ОБРЕЗАЛИ данные.

Чтобы команда TRIM успела запуститься, я сделал rm /mnt/testfile && sync && sleep 120 перед выполнением проверки.

Одна вещь, которую следует отметить, если вы пытаетесь выполнить тот же тест: у SSD есть блоки стирания, с которыми они работают (я не знаю размер стираемых блоков Crucial m4). Когда файловая система отправляет команду TRIM на диск, диск стирает только полный блок; Если команда TRIM указана для части блока, этот блок не будет TRIM'd из-за оставшихся действительных данных в блоке стирания.

Итак, чтобы продемонстрировать, о чем я говорю (вывод sectors.pl сценарий выше). Это тестовый файл на SSD. Точки - это секторы, содержащие только нули. Плюсы имеют один или несколько ненулевых байтов.

Тестовый файл на диске:

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

Тестовый файл удален с диска (после sync && sleep 120):

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

Похоже, что первый и последний секторы файла находятся в блоках стирания, отличных от остальной части файла. Поэтому некоторые сектора остались нетронутыми.

Вывод из этого: некоторые инструкции по тестированию Ext4 TRIM просят пользователя проверить только то, что первый сектор был обрезан из файла. Тестировщик должен просмотреть большую часть тестового файла, чтобы действительно увидеть, успешно ли было выполнено TRIM.

Теперь, чтобы выяснить, почему вручную отправленные команды TRIM, отправленные на SSD через карту RAID, работают, а автоматические команды TRIM - нет ...

Вот методика тестирования для 10.10 и EXT4. Может, это поможет.

https://askubuntu.com/questions/18903/how-to-enable-trim

Да, и я думаю, вам действительно нужен параметр discard на монтировании fstab. Не уверен, нужен ли параметр SSD, поскольку я думаю, что он должен автоматически определять SSD.

Некоторые вещи, о которых стоит подумать (чтобы помочь ответить на ваш вопрос «Я что-то упустил?»):

что такое / dev / sda? один SSD? или (аппаратный?) RAID-массив SSD?
если последнее, то какой RAID-контроллер?
а ваш рейд-контроллер поддерживает TRIM?

и наконец,

дает ли ваш метод тестирования ожидаемые результаты, если вы отформатируете / dev / sda1 чем-то другим, кроме btrfs?

Для btrfs вам понадобится discard возможность включить поддержку TRIM.

Вот очень простой, но рабочий тест на функциональность TRIM: http://techgage.com/article/enhibited_and_testing_ssd_trim_support_under_linux/2

Практически все твердотельные накопители с интерфейсом SATA используют какую-то файловую систему со структурой журнала, которая полностью скрыта от вас. Команда SATA 'trim' сообщает устройству, что блок больше не используется и что базовая файловая система структуры журнала может прошить его / если / соответствующий блок стирания (который может быть значительно больше) / only / содержит блоки, отмеченные обрезкой.

Я не читал стандартные документы, которые здесь: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim, но я не уверен, есть ли какая-либо гарантия стандартного уровня, что вы сможете увидеть результаты команды обрезки. Если вы видите, что что-то изменилось, например, обнуление первых нескольких байтов в начале блока стирания, я не думаю, что есть какая-либо гарантия, что это применимо к различным устройствам или, возможно, даже к версии прошивки.

Если вы думаете о том, как может быть реализована абстракция, должно быть возможно сделать результат команды обрезки полностью невидимым для того, кто просто читает / записывает блоки. Кроме того, может быть трудно определить, какие блоки находятся в одном блоке стирания, поскольку это должен знать только уровень трансляции флэш-памяти и, возможно, переупорядочил их логически.

Возможно, есть команда SATA (возможно, команда OEM?) Для получения метаданных, связанных с уровнем трансляции флэш-памяти SSD?