Почему файловая система BTRFS для Linux является посредственностью в обычном использовании
Что можно сказать про BTRFS? Человек никогда не использовавший эту файловую систему наверняка попытается найти информацию в интернете, там говорится, что это стандарт следующего поколения для Linux, большие файлы, моментальные снимки, надёжность!
реклама
А в Википедии вовсе говорят, что BTRFS иногда даже опережает EXT4 в производительности! Просто чудо какое-то, а не файловая система!
реклама
Интересно, почему BTRFS ещё не захватил мир? Ну, даже не знаю, наверное потому что в линуксах постоянно случается всякое дерьмо... Копировал вот однажды 140 ГиБ данных на HDD с BTRFS файловой системой, скорости были никакие, да и софт в системе постоянно зависал слегка при копировании, и это меня очень напрягло:
В итоге были созданы 4 раздела в пределах одного диска специально для проверки, и раздел с BTRFS откровенно дерьмово работал, да и софт в системе всё равно немного зависал при копировании:
реклама
Это побудило меня начать ковырять настройки Linux (sysctl.d), и спустя некоторое время танцы с бубном побороли зависание софта во время копирования данных, однако со скоростями всё равно была беда, как бы я не танцевал с бубном вокруг конфига:
Однако тогда у меня не было времени писать статью про это, потому отложил до следующего раза, и вот он настал, разве что система с того момента уже перезагружалась несколько раз, конфиги допилены сильнее, в общем условия изменились, но всё же повторно провести тесты не помешает, вдруг это с линуксом происходило какое-то дерьмо, а не файловой системой, хотя тогда только у BTRFS были серьёзные проблемы со скоростями:
![]() |
![]() |
![]() |
Причём важно заметить, на отвал USB 3.0 это не похоже, ведь с другими файловыми системами на том же диске скорость значительно превышала лимит USB 2.0, да и копирование на другой USB 3.0 HDD с файловой системой NTFS прекрасно работало в полную скорость диска, только BTRFS разделы работали крайне медленно, так что это выглядело весьма странно, и всё указывало именно на файловую систему:
![]() |
![]() |
реклама
Сейчас у меня есть 4 раздела с exFAT, NTFS (форматирован из под Linux), BTRFS и EXT4 на одном диске, именно эти разделы будут снова тестироваться:
В качестве тестового накопителя выступает внешний 2.5" USB 3.0 HDD.
Важно заметить перед началом экспериментов, у меня "dirty" кэш в ОЗУ ограничен до 48/64 МиБ (vm.dirty_bytes, vm.dirty_background_bytes), в других дистрибутивах Linux, как правило, размер "dirty" кэша имеет неадекватно большой размер, что может приводить к явно неадекватным скоростям при копировании, и даже потере информации после завершения процесса копирования, даже если выждать некоторое время перед извлечением накопителя, но по теме потери информации есть другая статья:
С нюансами определились, можно приступать к экспериментам! Начнём с бенчмарка KDiskMark, O_DIRECT и Flush Pagecache включены:
По синтетическому тесту весьма забавная картина, BTRFS имеет неадекватно большие скорости записи в режиме случайного доступа, а NTFS (форматировано из под Linux) показала в целом худший результат, что странно:
![]() |
![]() |
![]() |
![]() |
Но как обстоят дела с реальным копированием данных на разделы? Чтобы HDD не был узким местом, хоть он и подключен через USB 3.0, копировать буду что-нибудь находящееся на SSD накопителях, начнём с двух крупных файлов общим размером 4 ГиБ:
А замерять время копирования буду по видеозаписи, мне просто лень вручную ставить таймеры и засекать время, тем более ручная работа это повышенный шанс допустить лишние ошибки:
Первой протестирована BTRFS, в конце копирования скорость была около 70 МиБ/с, потрачено 57 секунд:
![]() |
![]() |
![]() |
Далее exFAT, под конец скорость ~76 МиБ/с, занято ~50 секунд времени:
![]() |
![]() |
![]() |
EXT4 показала лучшие результаты, скорость в конце 91 МиБ/с, потрачено времени всего ~43 секунды:
![]() |
![]() |
![]() |
И вот NTFS, скорость в конце 98 МиБ/с, времени потрачено ~47 секунд, это даёт среднюю скорость около 87 МиБ/с, (~92 MB/s), что явно больше 74-86 MB/s измеренных линуксоидным синтетическим тестом KDiskMark:
![]() |
![]() |
![]() |
Итого BTRFS показала худший результат при работе с большими файлами, а ведь в преимуществах рассказывали, что эта файловая система предназначена для больших файлов, или может мои файлы недостаточно большие...
NTFS отстала в целом только от EXT4, причём незначительно.
Ну да ладно, время перейти к маленьким файлам!
Теперь источником будет NVMe SSD Samsung 970 PRO 512GB, чтобы наверняка не был узким местом, а в качестве набора выступает почищенный от крупных файлов VENV от сборки SD WebUI Neuro Linux v2, 67 492 файла общим размером 1.9 ГиБ:
BTRFS, копирование завершено за 31 секунду:
![]() |
![]() |
![]() |
На этот раз exFAT показал себя хуже всех, 3 минуты 40 секунд:
![]() |
![]() |
![]() |
EXT4 справилась за 38 секунд, что даже больше, чем при копировании на раздел BTRFS:
![]() |
![]() |
![]() |
NTFS справилась за 1 минуту 17 секунд:
![]() |
![]() |
![]() |
Ну что сказать, сейчас BTRFS показала себя весьма неплохо, а это значит лишь одно, у меня была какая-то проблема с линуксом, либо с файловой системой, которая сама собой решилась спустя несколько перезагрузок, причем проблема была специфическая, и затрагивала в основном только BTRFS...
Усложним задачу.
Допустим человек уже 3 дня без перезагрузок, и он даже не задумывался о том, чтобы чистить кэш быстрого доступа перед копированием очередной порции данных, и вот, кэш успешно заполнен на 52 ГиБ, да, у меня 64 ГиБ ОЗУ, и чтобы заполнить всё кэшем, мне пришлось скопировать три виртуальные машины общим размером почти 60 ГиБ с одного SSD на другой... Но когда человек просто пользуется системой, этот кэш сам собой заполняется, есть конечно ещё и буферы, они тоже могут занимать много памяти, но в целом это всё считается "доступной" памятью:
Чтобы исключить "память файловой системы", копировать буду уже другие данные, хм, что бы взять... Пожалуй возьму папку с игрой FlatOut, 3827 файлов на ~1.5 ГиБ:
А чтобы было интереснее, сейчас начну с EXT4 раздела, ведь на чтение данных с накопителя тоже нужно время, и первое чтение происходит в кэш ОЗУ, последующие копии уже будут браться из ОЗУ, а не накопителя источника, так что я по факту даю сейчас преимущество файловой системе BTRFS, хотя SSD и так гораздо быстрее HDD, но всё же...
Итого EXT4 17 секунд, BTRFS 16 секунд, exFAT 43 секунды, NTFS 24 секунды, теперь BTRFS уже не имеет особого разрыва между EXT4:
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Пожалуй на этом можно закончить, ведь сейчас ничего особо интересного больше нет, Linux/BTRFS "исправился" сам собой спустя несколько перезагрузок системы, хотя кто знает, вдруг BTRFS снова "упадёт" со временем, и я опять буду думать - какого рожна происходит...
Точно, нужно бы подвести результаты в наглядную таблицу:
Теперь отлично видно, что у BTRFS хоть и худший результат при копировании больших файлов, но лучшие результаты при копировании мелких файлов. Главное чтобы "сюрпризы" случались как можно реже, а то я уже серьёзно задумывался переформатировать HDD в EXT4 вместо BTRFS, но пока что дам ещё один шанс файловой системе "следующего поколения"...
В конце концов BTRFS весьма неплохо пока себя показывает в плане надёжности хранения по моим личным наблюдениям, не разваливается как EXT4, и в гораздо меньшей степени NTFS при внезапном отключении накопителя, однако если проблема отмеченная в начале статьи будет часто себя проявлять, это точно будет решающим фактором, чтобы сменить файловую систему на "прошлое поколение".
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила