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

21

Мы рассматриваем возможность использования 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):

  • Вручную TRIM диски перед запуском: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Убедитесь, что диск TRIM'd: ./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
  • Посмотрите, что тестовый файл TRIM'd с диска: ./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";

Моя методика тестирования несовершенна? Я что-то здесь упускаю?

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

linux ubuntu ssd btrfs trim Шейн Мейерс
источник
1
Я полностью поддерживаю тестирование самых передовых вещей, но только чтобы вы знали, что на данный момент у btrfs нет fsck, который на самом деле, вы знаете, исправляет вещи: btrfs.wiki.kernel.org/index.php/Main_Page - так просто следите за этим.
Мэтт Симмонс
@Matt - Хороший вопрос о пропавшем fsck. Насколько я понимаю, первая версия fsck должна появиться в течение следующих нескольких недель, поэтому мы должны быть готовы к тому моменту, когда перейдем к производству. Кроме того, у нас будет несколько копий наших данных, поэтому, если мы потеряем одну копию, у нас будет еще как минимум две копии для восстановления. Но я полностью согласен с тем, что сейчас это не файловая система для людей с незаменимыми данными.
Шейн Мейерс
1
Вероятно, ничего не изменится, но вы можете попробовать запустить syncфайл после изменения файла.
zebediah49
Я хочу сказать, что я попытался запустить syncпосле удаления файла, и результаты остались прежними. Я проверю это дважды, хотя, когда вернусь в офис после выходных.
Шейн Мейерс
если вы не возражаете против кровопролития, рассматривали ли вы zfsonlinux.org ? родной (т. е. в ядре, а не в предохранителе) ZFS для linux. они близки к официальному «релизу» и имеют в своем распоряжении RC (включая PPA для Ubuntu - достаточно легко перестраивать и для Debian)
cas

Ответы:

4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шейн Мейерс
источник
Я подумал, что все команды HW RAID съели триммеры, приятно видеть, что все постепенно меняется. С другой стороны, с хорошими современными приводами TRIM имеет значение все меньше и меньше.
Рональд Поттол
4

Исходя из того, что я прочитал, в вашей методологии может быть недостаток.

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

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

cat / sys / block / sda / queue / discard_zeroes_data

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

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

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

chrishiestand
источник
3

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

/ubuntu/18903/how-to-enable-trim

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

Дейв Веффер
источник
2
Я пытался следовать инструкциям проверки Ext4 SSD, но они не работают из-за различий в работе BtrFS по сравнению с другими файловыми системами. Отсюда и рабочий процесс, который я придумал. Я использовал ssdопцию монтирования, чтобы BtrFS знал, что он использует свой специфичный для SSD код, даже если он должен автоматически обнаруживать. Я также попытался использовать discard(как отмечено выше), и это не помогло.
Шейн Мейерс
Ну что ж. Стоит
попробовать
1

Для btrfs вам нужна discardопция включения поддержки TRIM.

Очень простой, но рабочий тест для функционального TRIM находится здесь: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Павел Бродацкий
источник
1
Как я упоминал выше, я попробовал свое тестирование как с discardопцией, так и с ssdопцией. В документации по BtrFS часто упоминается ssdопция, поэтому я сфокусировал свое тестирование там, но ни один из вариантов не дал ожидаемого результата. Большинство веб-страниц, которые показывают, как тестировать TRIM, предназначены для Ext4 и т.п. BtrFS не может быть протестирован с использованием этих методологий из-за различий в дизайне файловой системы.
Шейн Мейерс
hdparm --fibmapФС агностик. Блок по указанному адресу LBA либо обнуляется, либо нет, независимо от того, является ли он опцией extN, btrfs, xfs, jfs ..., не ssdимеет значения для дифферента, см., Например, это обсуждение в списке рассылки btrfs : mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Павел Бродацкий
Я пытался использовать, hdparm --fibmapно он не работает на BtrFS. Если вы посмотрите на README wiper.sh (распространяемый вместе с hdparm), они прямо заявляют, что «вызовы FIEMAP / FIBMAP ioctl () абсолютно небезопасны при использовании в файловой системе btrfs». Итак, hdparm отсутствует, что очень плохо, поскольку это сделает тестирование намного проще. Я не знал, что этот ssdвариант не имеет ничего общего с TRIM, поскольку в документах не очень ясно о полезности этого варианта.
Шейн Мейерс
Спасибо за дополнительную информацию о ioctls, я не знал это. Я думаю, что лучшим местом для получения дополнительной информации может быть список рассылки btrfs. Вы получите информацию из первых рук оттуда.
Павел Бродацкий
1

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

  • что именно / dev / sda? один SSD? или (аппаратный?) RAID-массив из SSD?

  • если последний то какой контроллер RAID?

  • а ваш рейд-контроллер поддерживает TRIM?

и наконец,

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

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

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

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

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

Джошуа Хоблитт
источник