Найшвидша файлова система Linux на перегородках

Існує чималий інтерес до шиберних приводів. Вони розміщують доріжки даних так близько один до одного, що ви не можете записати в один трек, не переробляючи наступного. Це може збільшити потужність на 20% або близько того, але це призведе до проблем з посиленням запису. Зараз ведуться роботи над файловими системами, оптимізованими для дискових шин, наприклад, див: https://lwn.net/Articles/591782/

Деякі шипучі диски, такі як архів Seagate 8TB, мають область кешу для випадкових записів, що дозволяє гідну продуктивність у загальних файлових системах. Диск навіть може бути досить швидким на деяких загальних робочих навантаженнях, до 200 Мб / сек пише. Однак слід очікувати, що якщо кеш випадкового запису буде переповнений, продуктивність може постраждати. Імовірно, деякі файлові системи краще уникати випадкових записів взагалі, або шаблони випадкових записів, ймовірно, переповнюють кеш запису, знайдений на таких дисках.

Чи краще файлова система в ядрі Linux краще уникати покарання продуктивності шаруватих дисків, ніж ext4?

Структуровані файлові системи з інтуїтивно зрозумілим копіюванням і записом і журналом можуть забезпечити кращу ефективність роботи на гофрованих дисках, зменшивши скорочення випадкових записів. Еталонні показники дещо підтверджують це, однак, ці відмінності в продуктивності не характерні лише для гофрованих дисків. Вони також трапляються на недискримованому диску, який використовується як елемент управління. Таким чином, перемикання на гострий диск може не мати великого значення для вашого вибору файлової системи.

Файлова система nilfs2 дала досить хороші показники на диску SMR. Однак це було тому, що я виділив цілий розділ 8 ТБ, і тест лише написав ~ 0,5 ТБ, щоб очищувач нільфів не запускався. Коли я обмежив розділ на 200 ГБ, то орієнтири nilfs навіть не були успішно виконані. Nilfs2 може бути хорошим вибором продуктивності, якщо ви дійсно використовуєте "архівний" диск як архівний диск, де ви зберігаєте всі дані та знімки, записані на диску назавжди, оскільки тоді очищувач nilfs не повинен запускатися.

Я розумію, що накопичувач 8 Гб, який ST8000AS0002-1NA17Zя використовував для тесту, має область кешу ~ 20 ГБ . Я зробив змінити параметри файлового сервера filebench за замовчуванням, щоб набір орієнтирів був ~ 125 ГБ, більший за область кешу, що не визначається:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Тепер про фактичні дані. Кількість ops вимірює "загальну" продуктивність файлового сервера, тоді як ms / op вимірює затримку випадкового додавання і може бути використана як орієнтовний посібник щодо виконання випадкових записів.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Оскільки Seagate становить 5980 об / хв, можна наївно очікувати, що Toshiba буде на 20% швидше. Ці показники показують, що вони приблизно в 3 рази (на 200%) швидші, тому ці показники враховують пені за ефективність. Ми бачимо, що диск Shingled (SMR) все ще не може відповідати продуктивності ext4 на дисковому (PMR) диску. Найкращі показники були у nilfs2 з розділом 8 ТБ (тому очищувач не запускався), але навіть тоді він був значно повільнішим, ніж Toshiba з ext4.

Щоб зробити еталони вище зрозумілими, це може допомогти нормалізувати їх відносно продуктивності ext4 на кожному диску:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

Ми бачимо, що на диску SMR btrfs має більшу перевагу в загальних операційних можливостях, які він має на ext4, але штраф за випадкові додавання не такий драматичний, як співвідношення. Це може призвести до переходу на btrfs на диску SMR. З іншого боку, якщо вам потрібні випадкові додатки з низькою затримкою, цей орієнтир дозволяє запропонувати xfs, особливо в SMR. Ми бачимо, що хоча SMR / PMR може впливати на ваш вибір файлової системи, враховуючи навантаження, для якої ви оптимізуєтесь, здається більш важливою.

Я також провів орієнтир на основі горища. Тривалість прогонів мансарди (на повнороздільних дисках 8TB SMR) склала:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

У кожному випадку горищні сховища мали таку статистику:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

Додавання другої копії одного і того ж 1 ТБ диска на горище займало 4,5 години на кожній з цих трьох файлових систем. Негативний перелік орієнтирів та smartctlінформації знаходиться на веб- сайті: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Якщо ви rsync з дисковода SMR, переконайтеся, що файлова система встановлена read-onlyабо є noatimeопцією.

Інакше приводу SMR потрібно буде написати часову позначку для кожного зчитуваного файлу rsync, що призведе до значного погіршення продуктивності (приблизно від 80 мб / с до 3-5 мб / с тут) та шуму зносу / натискання голови.

Якщо у вас вже є завдання rsync, що працює з низькою продуктивністю, зупиняти його не потрібно, ви можете повторно виконати виконання вихідної файлової системи

sudo mount -o remount,ro  /path/to/source/fs

Ефект буде помітний не відразу, наберіться терпіння і почекайте 10-20 хвилин, поки накопичувач не закінчить записувати всі дані, що все ще знаходяться в його буферах. Ця порада перевірена і перевірена нормально.

Це може також застосовуватися при rsyncІНГ на якості SMR диска, тобто , якщо файлова система намагається оновити мітку часу після того, як файл був повністю записаний на диск. Це послідовне навантаження та величезні діапазони даних постійно переписуються, сприяючи зносу. Наступне може допомогти:

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Це потрібно зробити перед тим, як запустити rsync; інші фактори можуть зробити цю опцію незначною, тобто нерозподілене оновлення FAT / MFT, паралельне записування, якщо файлова система оптимізована головним чином для SSD тощо.

Спробуйте використовувати dd bs=32Mта змінити розмір файлової системи на цілі SMR, якщо ви все одно хочете створити резервну копію повних файлових систем (не потрібно встановлювати її та запускати rsync для транспортування кожного файлу в цьому випадку).

Фактичним обладнанням, яким користувався, був привід Seagate, керований SMR 8tb. Ваш пробіг може відрізнятися від іншого обладнання.