Should I use btrfs or Ext4 for my SSD?
Should I use btrfs (with discard, compress=lzo and space_cache options) or Ext4 (with discard option) for the SSD for my Ubuntu 11.10 (Oneiric) amd64 desktop root partition of my office machine? /home will be an HDD so fs reliability affects OS not my data.
4 Answers 4
According to the tests by phoronix it always depends on many factors. In one case Btrfs will be doing much better than EXT4 when reading large files on an SSD. Similarly while considering Disk transaction performance, Ext4 can perform better than the later.
You can have a look through these tests here, here and here (WARNING: Lengthy articles).
But summing altogether, Btrfs right now does not have a quantitative performance advantage over the EXT4 file-system, Even when using in the SSD mode.
So you can choose over Ext4 for now.
The articles are Sep 2011, Aug 9 2010 and May 29 2009 respectively. Focusing on the latest because I assume btrfs would be evolving over the last 2 years. The btrfs+LZO chart on page 4 is amazing for sequential read and write performance, but btrfs does badly with random writes so its definitely no to btrfs for DBs and VM images. I guess with root partition the load is mostly random reads, for which its not much better than ext4.
Within a few years Btrfs will turn into an better option than EXT4. Its a more promising file system 🙂
For those stumbling on this question in 2016. Use ext4. I tried btrfs and the difference is substantial. Over a 10-day period write IOs to ext4 amounted to 17,800 sectors. Btrfs? 490,400 sectors. Same SSD, identical filesystem, different partitions. Basically, same workload.
Both ext4 and btrfs go «quiet» when there is zero write activity on the drive. That’s good.
Ext4 will write the modified data, plus some overhead. Overhead relates to the data written. A 4K write (1 block) pushes about 50-80 blocks of overhead at the next commit. (The ext4 Journal is fully enabled)
Modify a single 4K block on btrfs and you’ll push between 4000-5000 blocks of overhead at the next commit. Default commit is 30 seconds, I believe. I used 120.
Now, it depends on how you use the SSD. As root, there is typically a fairly constant, low level, stream of writes going on. Log files, ntp drift files, man db rebuilds, opensm topology updates, etc, etc. Each event will hammer a btrfs drive with another 4000-5000 writes.
The 10 day numbers above are for my «write limited» SSD. The bulk of those 17,800 sectors were the result of a smallish system update. One the btrfs copy did not suffer. My writers are, exactly, ntp drift, opensm topology, and man db updates (nightly). Nothing else hits that disk, except actively initiated things like system upgrades, vim /etc/whatever , etc.
On whole SSDs will suffer a lot of writes, really. I just can’t see the point in wasting them just ‘cuz the news media is chasing bunnies and rainbows. If you want to pay this price for COW, go for it. For «performance», not so much. It’s an SSD and you could probably put the worst «file system» known to man on it, and still get some level of performance — just by brute force. Ext4 is, by far, not the worst file system known to man.
No monthly fs check. Try the script below. It’s a 100% hack, won’t work for md mountpoints,
#! /bin/bash dev=`cat /proc/mounts | grep " $1 " | awk ''` x=`basename $dev` vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk ''` vmx=`vmstat -d | grep $vmnam | awk ''` lbax=`smartctl -a $dev | grep LBA | awk ''` 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 ''` lba=`smartctl -a $dev | grep LBA | awk ''` if [ "$vm" != "$vmx" ] then tim=`date +%s` dif=`dc It will tell you how many blocks were written, according to the drive itself, and exactly which files were updated. Needs root privs. See for yourself. I run SSD on root filesystem, and call the script stat.sh. So. sudo ./stat.sh /
Сравнение файловых систем Linux: Btrfs и Ext4
Давно меня интересует вопрос о файловых системах. Их много, есть фавориты. Периодически натыкаюсь на упоминании, сравнения, разговоры, но сам плаваю в вопросе. Так что же лучше и почему, что выбрать ? . . Тут я попытался ответить на этот вопрос.
Btrfs
Файловая система, которая активно использует метаданные в своей работе, что ускоряет процесс, но при утере метаданных теряются и сами данные.
При копировании данные не записываются целиком, записи подлежит лишь изменённая часть.
Из-за принципа работы хорошо подходит для создания снимков.
Управление томами и сжатие данных уже содержатся в ФС, поэтому не требуется установка дополнительного ПО.
Сама ФС была разработана в 07 году с прицелом на современные устройства, содержит оптимизации для работы с SSD, процессы обнаружения и исправления ошибок, поддерживается дефрагментация и дедупликация в реальном времени (Дедупликация — процесс сжатия за счет удаления неиспользуемых дубликатов файлов).
Формат хранения данных уже заморожен, а это основа ФС, но кодовая база разрабатывается. Периодически улучшения появляются и в самом ядре, над улучшением работают различные крупные компании. Файловая система Btrfs очень интересная и перспективная.
Ext4
Пожалуй, самая известная и часто встречаемая ФС, которая используется по умолчанию в большинстве дистрибутивов. Наиболее стабильна, так как развитие положено ещё в прошлом веке, планомерное развитие из Ext > Ext2 > Ext3.
Использует в своей работе журналирование, что даёт большую надёжность для файлов, но снижает скорость. Если появляется ошибка, то ФС возвращается к предыдущей версии из журнала. Благодаря журналу, даже при сбое записи ФС остаётся в безопасности.
В Ext4 была добавлена дефрагментация в реальном времени.
Не смотря на почтенный возраст, всё ещё разрабатывается. Разработчики планируют заставить ФС работать с контрольными суммами а автоматическом режиме и улучшить квоты, переложить их на ядро, это улучшит производительность.
Получила в своё распоряжение различные современные механизмы для улучшения производительности, включая работу с SSD, но структура устарела.
Журнал, который используется в работе и часто встречается в описании — принцип работы, при котором транзакции записываются сначала в журнал, а изменение/запись происходят уже после.
Другие
В этом материале я не упомянул о таких вариантах как ZFS, ReiserFS, JFS и F2FS.
ZFS изначально была открытой, развивалась в Sun Microsystems, но потом выкуплена Oracle, её код закрыт, а форк последней доступной версии выпущен как OpenZFS. Официально в ядре отсутствует, потому что её лицензия конфликтует с GPL, а Л. Торвальдс высказывается против. Но разработчики дистрибутивов могут обеспечить её поддержку через слой совместимости. По ряду параметров схожа с Btrfs, которая распространяется под свободной лицензией и официально поддерживается в ядре.
Все они либо не лучше, либо хуже по каким-либо параметрам, чем вышеупомянутые. Такое разнообразные ФС создаёт «Проблему выбора», на практике отличия между ними не заметны. Поэтому для меня вывод остался прежним: Ext4 для дисков — старой технологии записи, Btrfs для SSD — более современных устройств.
В комментариях оставлю ссылку на скриншот из программы GParted. Там наглядно видно, что другие ФС не имеют такой широкой поддержки одной из самых известных и распространённых программ для работы с разделами.
btrfs vs ext4
Ставлю арчик на ноут с ssd. Задался вопросом выбора ФС. Знаю что, btrfs это фичасто, стильно, модно и молодёжно, и, по слухам, работает быстрее ext4. Так ли это? С другой стороны, от фс мне нужно, чтобы она просто, быстро и надежно работала. А ext4 вроде как золотой стандарт. Если я не буду использовать фичи btrfs, то её не имеет смысл ставить?
Знаю что, btrfs это фичасто, стильно, модно и молодёжно
что не помешало редхату отправить ее в деприкейтед
Ты свой ssd собираешься превратить в одну единую монолитную файлопомойку?
насколько я слышал, работает медленнее практически всего, кроме ntfs-3g
Нада спапшоты btrfs? Выбирай её. Нет – ext4
если тебе ехать, то ext4, а если шашечки - ну ты понял
самое интересное сотрудник редхата пишет, что многие функции btrfs доступны в других фс. Поэтому скрипач не нужен
. btrfs уже «почти готова к производству» уже много лет, но так и не достигла той стадии, когда была готова. В то же время многие функции, которые предоставляет btrfs, теперь доступны с помощью других более зрелых и стабильных технологий хранения, таких как ext4, XFS, LVM и т. Д. Мы приложили значительные усилия для улучшения этих технологий до уровня, на котором уже сейчас существуют предложения Red Hat. Они охватывают почти весь набор функций btrfs. jtad ★ ( 12.04.20 19:36:37 MSK )
Последнее исправление: jtad 12.04.20 19:38:00 MSK (всего исправлений: 1)
Если я не буду использовать фичи btrfs, то её не имеет смысл ставить?
Нет, получишь только падение производительности. А так - XFS
И никто не помянул «Похожие темы» внизу страницы, хотя наверняка в них участвовали.
Потому что им надо продвигать свою XFS, вне красношляпого мирка btrfs живёт и процветает.
У них изначально ставка на xfs+lvm, а btrfs сейчас SUSE продвигает.
Даешь нормальный говносрач! Ура, товарищи! Если серьезно, то пользовать btrfs можно. Я сам ее использую с lzo сжатием. Но не могу сказать, что есть разительная разница в производительности по сравнению с ext4. Хотя пакман радует скоростью работы. На мой взгляд, btrfs не настолько глючная, как ее малюют хейтеры.
anti_win ★★ ( 12.04.20 19:49:40 MSK )
Последнее исправление: anti_win 12.04.20 19:52:18 MSK (всего исправлений: 1)
Потому что им надо продвигать свою XFS
хочется верить что делают это не без причины. Правда lvm, которую они предлают в связи, просто медленное уг
Но не забывай, что нужно монтировать с autodefrag, иначе фрагментация будет зачОтная.
lvm, которую они предлают в связи, просто медленное уг
А «твой» autodefrag файлово-инодную таблицу перелопачивает, или наоборот превращает её в «винегрет»?
Я структуру инодов не изучал/не делал сравнений. Внешне, эффектов фрагментации не наблюдается.
Да плевал я на фраги! Что с затупами?
ext4+lvm по фичам почти равны btrfs. ext4 можно гибко подстроить под разные сценарии эксплуатации на этапе создания и частично в процессе использования, нужно только документацию осилить. ext4 и lvm используются дольше чем btrfs, поэтому лично я считаю их более надежными. Лично я не вижу смысла в использовании btrfs. Последней каплей в чаше моего терпения был глюк с невозможностью стереть данные с переполненной btrfs по причине переполнения btrfs. Прочитал что это не баг, а фича такая, по дизайну, вылечил растягиванием на внешнюю флешку и удалением, после чего решил больше btrfs не использовать.
потому что lvm надстройка над фс. Я одно время баловался с малиной и пихал по 5 hdd в одну группу. По отдельности скорость выше более чем в 2 раза
jtad ★ ( 12.04.20 19:59:11 MSK )
Последнее исправление: jtad 12.04.20 19:59:33 MSK (всего исправлений: 1)
пихал по 5 hdd в одну группу
Btrfs так можен? Ну коли сравниваешь.