Чи варто використовувати btrfs або Ext4 для свого SSD?


16

Чи слід використовувати btrfs (з параметрами відкидання, стиснення = lzo та space_cache) або Ext4 (з опцією відкидання) для SSD для мого кореневого розділу на робочому столі Ubuntu 11.10 (Oneiric) amd64?

/ home буде HDD, тому надійність fs впливає на ОС, а не на мої дані.

Відповіді:


13

Згідно з тестами на форонікс, це завжди залежить від багатьох факторів. В одному випадку Btrfsце буде набагато краще, ніж EXT4при читанні великих файлів на SSD. Аналогічно, розглядаючи ефективність дискових транзакцій, вона Ext4може працювати краще, ніж пізніше.

Ви можете ознайомитись з цими тестами тут , тут і тут (УВАГА: Тривалі статті).

Але підсумовуючи загальний результат , Btrfs зараз не має кількісної переваги у продуктивності порівняно з файловою системою EXT4 , Навіть при використанні в режимі SSD.

Тож ви можете обрати більше Ext4.


2
Статті відповідно: вересень 2011, 9 серпня 2010 та 29 травня 2009 року. Орієнтуючись на останнє, тому що я припускаю, що btrfs розвиватиметься протягом останніх 2 років. Діаграма btrfs + LZO на сторінці 4 є дивовижною для послідовної продуктивності читання і запису, але btrfs погано справляється зі випадковими записами, тому її напевно немає btrfs для зображень DB та VM. Я думаю, що з кореневим розділом навантаження здебільшого є випадковим зчитуванням, для якого воно не набагато краще, ніж ext4.
Грем

Протягом кількох років Btrfs перетвориться на кращий варіант, ніж EXT4. Його більш перспективна файлова система :)
NBK

7

Для тих, хто спотикається з цим питанням у 2016 році ... Використовуйте ext4. Я спробував btrfs, і різниця суттєва. Протягом 10-денного періоду запис IO до ext4 становив 17 800 секторів. Btrfs? 490 400 секторів. Той самий SSD, однакова файлова система, різні розділи. В основному, таке ж навантаження.

І ext4, і btrfs залишаються "тихими", коли на диску накопичується нульова активність запису. Це добре.

Ext4 запише змінені дані, а також додаткові накладні витрати. Накладні витрати стосуються записаних даних. Запис 4K (1 блок) штовхає приблизно 50-80 блоків накладних витрат на наступному коміті. (Журнал ext4 повністю включений)

Змініть один блок 4K на btrfs, і ви натиснете між 4000-5000 блоками накладних витрат на наступному коміті. Я вважаю, що за замовчуванням здійснюється 30 секунд. Я використовував 120.

Тепер, це залежить від того, як ви використовуєте SSD. Як корінь, як правило, існує досить постійний, низький рівень потоку записів. Файли журналів, файли дрейфу ntp, перебудова db man, відкриття оновлень топології тощо, і т.д.

Наведені вище 10-денні цифри - це мій SSD для "запису з обмеженим доступом". Основна частина цих 17 800 секторів була результатом невеликого оновлення системи. Один копія btrfs не постраждав. Мої автори - це, точно, ntp дрейф, топологія openm та оновлення людини db (щоночі). Більше нічого не потрапляє на цей диск, крім активно ініційованих речей, таких як оновлення системи vim /etc/whateverтощо.

На цілому SSD буде страждати багато записів, дійсно. Я просто не бачу сенсу витрачати їх просто тому, що ЗМІ переслідують зайчиків та веселок. Якщо ви хочете заплатити цю ціну за КОР, перейдіть на це. Для «продуктивності» не так вже й багато. Це SSD, і ви, мабуть, могли поставити на нього найгіршу відому людині "файлову систему", і все-таки отримати деякий рівень продуктивності - просто грубою силою. На жаль, Ext4 - це не найгірша відома людині файлова система.

Немає щомісячної перевірки фс. Спробуйте сценарій нижче. Це 100% хак, не працює для md точок кріплення,

#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
    vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
    lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
    if [ "$vm" != "$vmx" ]
    then
        tim=`date +%s`
        dif=`dc <<< "$vm $vmx - p"`
        lbad=`dc <<< "$lba $lbax - p"`
        timd=`dc <<< "$tim $timx - p"`
        echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
        vmx="$vm"
        lbax="$lba"
        timx="$tim"
        find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
        touch "$tmpnam" 
    fi
    sleep 1 
done

Він розповість, скільки блоків було написано, відповідно до самого диска, і які саме файли були оновлені. Потребує кореневих приват. Побачте самі. Я запускаю SSD в кореневій файловій системі і викликаю скрипт stat.sh. Так...sudo ./stat.sh /


Мені не подобається ваш метод порівняння. Наприклад, починається щомісячна перевірка фс, і ви отримуєте ці результати. Btrfs за замовчуванням зараз майже скрізь, і з поважної причини.
Барафу Альбіно

Немає щомісячної перевірки фс. Спробуйте сценарій нижче. Це 100% хак, не працюватиме на md
точках монтажу

2
Чому такі великі писати накладні? Ви заявили, що 1 блок створив 50-80 блоків, написаних навіть на ext4 - це в 40 разів більше, ніж потрібно. Чому?
Golar Ramblar

я сумніваюся, чи це все-таки вірно наприкінці 2018 року. У своєму тесті я порівняв суму, написану відповідно до iotop та smartctl, і виявив, що останній заявляв у 3 рази більше, ніж колишній (ext4).
Майкл

2

Востаннє я тестував її, і я ще ніде не чув про те, як ext4 поїдає твердотільні носії інформації. (thumbdrives, твердотільні накопичувачі тощо) Я не рекомендую використовувати його на такому пристрої. Використовуйте замість ext3. У більшості випадків на SSD ви все одно не зможете визначити різницю.

BTRFS ще не зовсім стабільний. Однак він досить стабільний для некритичних програм. Це те, що я використовую для створення завантажувальних флешок. Якщо ви використовуєте компреси = zlib і ssd як параметри монтажу, стиснення компенсує нижчі швидкості запису більшості твердотільних носіїв інформації, а ssd змінює алгоритм розподілу на той, який працює на таких пристроях значно краще і доповнить будь-які поганий рівень зносу обладнанням. Єдиною областю продуктивності, яка все ще залишається проблемою, є те, що синхронізація дзвінків відбувається повільно. Це не є проблемою для загального використання, але dpkg синхронізує дзвінки після кожної операції, тому встановлення та оновлення програмного забезпечення може бути повільним. BTRFS також пропонує знімки та інші вдосконалені функції, які є досить корисними за певних обставин.

Якщо ви вирішили перейти з BTRFS, не забудьте скористатися дистрибутивом, використовуючи ядро ​​3.2.0-2 або новішу версію. 3.1.x при необхідності працює. Для старих ядер вам потрібно буде самостійно скласти останні модулі BTRFS. Вбудовані майже стабільні, але виправлення помилок не працює в старих версіях, що може залишити вас затокою, якщо щось піде не так. В останніх версіях є fsck, який фактично може усунути найпоширеніші несправності.

Одного останнього застереження, я чув повідомлення про те, що свопфіли у файловій системі BTRFS пошкодять його. Ця проблема, можливо, була виправлена, але обов’язково уважно перевірте її перед її впровадженням.

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


2

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


2
Чи можете ви надати посилання на прочитану статтю чи іншу ідентифікаційну інформацію для цієї статті?
Елія Каган

Я спробую знайти цю статтю конкретно. Пам'ятайте, що це твердження знайдено в Інтернеті під час серфінгу в магазині сигар. Завантажте лінійку читання та домашнє завдання, перш ніж використовувати ext4 на SSD. Подивіться статті на такі речі, як TRIMM та оптимізація. Що б ви не робили, не будьте схожими на мене і починайте отримувати помилки вводу-виводу в таких командах, як "sudo reboot" через вісім місяців.
user75153
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.