Перевірте підтримку 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):

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

Чи виявлена ​​помилка моєї методології тестування? Я чогось тут пропускаю?

Дякую за допомогу.


1
Я повністю підтримую тестування крайових речей, але просто так, щоб ви знали, на даний момент btrfs не має fsck, який насправді, ви знаєте, виправляє речі: btrfs.wiki.kernel.org/index.php/Main_Page - так просто стежте за цим.
Метт Сіммонс

@Matt - Хороший момент щодо відсутнього fsck. Я розумію, що перша версія fsck повинна надходити протягом найближчих кількох тижнів, тому ми повинні бути охоплені часом, коли ми перейдемо до виробництва. Крім того, у нас буде кілька копій наших даних, тому якщо ми втратимо одну копію, ми маємо принаймні ще дві копії, з яких можна відновити. Але я повністю згоден, що це не файлова система для людей з незамінними даними.
Шейн Мейерс

1
Напевно, нічого не зміниться, але ви також можете спробувати запустити файл syncпісля того, як утиснути файл.
zebediah49

Хочу сказати, що я спробував запустити a syncпісля видалення файлу, і результати все ще були однаковими. Я ще раз перевірю це, хоча коли я знову в офісі після закінчення вихідних.
Шейн Мейерс

якщо ви не заперечуєте проти кровоточивості, чи вважали ви zfsonlinux.org ? рідний (тобто в ядрі, не запобіжник) ZFS для Linux. вони близькі до офіційного "випуску" і мають доступні RC-адреси (включаючи PPA для Ubuntu - досить просто для відновлення для debian)
cas

Відповіді:


4

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

Обладнання, яке використовується для цього тестування:

  • Найважливіший m4 SSD 512 Гб
  • 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-накопичувачах є блоки стирання, над якими вони працюють (я не знаю розміру блоків вирішального значення m4 стирання). Коли файлова система надсилає команду TRIM на привід, привід видалить лише повний блок; якщо команда TRIM вказана для частини блоку, цей блок не буде TRIM'd через інші дійсні дані в блоці стирання.

Отже, щоб продемонструвати те, про що я говорю (вихід sectors.plсценарію вище). Це з тестовим файлом на SSD. Періоди - це сектори, які містять лише нулі. Плюси мають один або декілька ненульових байтів.

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

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

Тестовий файл, видалений з диска (після a sync && sleep 120):

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

Здається, перший і останній сектори файлу знаходяться в інших блоках стирання, ніж у решті файлу. Тому деякі сектори залишилися недоторканими.

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

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


Я подумав, що всі HW RAID їли обрізні команди, приємно бачити, що все повільно змінюється. З іншого боку, при хороших сучасних накопичувачах TRIM має значення все менше.
Рональд Поттол

4

Виходячи з того, що я прочитав, може бути недолік у вашій методиці.

Ви припускаєте, що TRIM призведе до того, що ваш SSD занулює блоки, які були видалені. Однак це часто не так.

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

cat / sys / block / sda / queue / discard_zeroes_data

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

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

До речі, я шукав надійний спосіб перевірити TRIM, і ще не знайшов його. Я хотів би знати, якщо хтось знайде спосіб.


3

Ось методика тестування 10.10 та EXT4. Можливо, це допоможе.

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

О, і я думаю, вам потрібен параметр відкидання на кріпленні fstab. Не впевнений, чи потрібен параметр SSD, оскільки я думаю, що він повинен автоматично виявити SSD.


2
Я намагався дотримуватися інструкцій з верифікації Ext4 SSD, але вони не працюють через відмінності в тому, як працює BtrFS порівняно з іншими файловими системами. Отже, робочий процес, який я придумав. Я використовував параметр ssdmount, щоб переконатися, що 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 .
Paweł Brodacki

Я спробував використовувати, hdparm --fibmapале це не працює на BtrFS. Якщо ви подивитеся на wiper.sh README (розподілений поряд з hdparm), вони прямо заявляють, що "виклики FIEMAP / FIBMAP ioctl () є абсолютно небезпечними при використанні у файловій системі btrfs." Тож hdparm вийшов, що дуже погано, оскільки це зробило б тестування набагато простіше. Я не знав, що ssdопція не має нічого спільного з TRIM, оскільки документи не дуже зрозуміли корисність цього варіанту.
Шейн Мейерс

Дякую за додаткову інформацію про йоктли, я цього не знав. Я думаю, що найкращим місцем для запиту додаткової інформації може бути розсилка btrfs. Ви отримаєте інформацію з перших рук звідти.
Paweł Brodacki

1

Деякі речі, про які варто подумати (щоб допомогти відповісти на запитання "я щось пропускаю?"):

  • що саме таке / dev / sda? єдиний SSD? або (апаратний?) масив RAID SSD-дисків?

  • якщо останній, то який саме RAID-контролер?

  • і чи підтримує ваш рейдовий контролер TRIM?

і, нарешті,

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

1

Практично всі SSD з інтерфейсом SATA запускають якусь файлову систему журналу, яка повністю прихована від вас. Команда "обрізка" SATA повідомляє пристрою, що блок більше не використовується та що файлова система базової структури журналу може його спалахнути / якщо / відповідний блок стирання (який може бути значно більший) / лише / містить блоки, позначені обрізкою.

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

Якщо ви думаєте про те, як може бути реалізована абстракція, слід зробити команду обрізки абсолютно непомітною для блоків, які просто читають / записують. Крім того, може бути важко сказати, які блоки знаходяться в одному блоці стирання, оскільки тільки шар перекладу флеш-пам'яті повинен знати це і, можливо, їх логічно переупорядкував.

Можливо, є команда SATA (можливо команда OEM?) Для отримання метаданих, пов'язаних із шаром флеш-трансляції SSD?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.