LINUX.ORG.RU

Стабильна ли btrfs сейчас ?

 , , , ,


1

4

Безопасно ли сейчас использовать btrfs, как основную файловую систему ? Просто многие промышленые решения уже используют btrfs (fedora, steamdeck), видимо не просто так. И какие опции стоит использовать, например есть ли вообще смысл от сжатия zstd ? Или есть ли опции которые значительно замедляют или ускоряют работу файловой системы ? Та и вообщем какие есть нюансы при использование btrfs ?



Последнее исправление: pcoder (всего исправлений: 2)

Дома использую btrfs уже лет 10, если не больше. Никаких проблем. Сжатие btrfs использую последние несколько лет, эффект есть очень заметный. Вот, например:

# compsize /home
Processed 179871 files, 153631 regular extents (165025 refs), 101829 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       90%       45G          49G          50G
none       100%       43G          43G          42G
zstd        29%      1.8G         6.4G         7.4G
prealloc   100%      520K         520K          22M

Со сжатием можно вполне заниматься разработкой кучи проектов на ноуте с 256 Гб SSD, место не заканчивается никогда.

emorozov
()

Просто многие промышленые решения уже используют btrfs (fedora, steamdeck), видимо не просто так.

Видимо. Т.е. выбирать не ФС, а решение, чтоб было куда обратиться за поддержкой.

vvn_black ★★★★★
()

Смысл есть, ФС стабильна, опции — noatime,discard=async (если ядро старое, то ещё space_cache=v2, в новых это дефолт), нюансы — запарное обслуживание и недоразвитый тулинг.

intelfx ★★★★★
()
Ответ на: комментарий от HerbertHoover

Btrfs (как и все современные ФС) проектируются именно с учётом такой устойчивости. С этой ФС можно потерять данные только с плохим железом, которое неправильно работает с аппаратной буферизацией записи.

intelfx ★★★★★
()

Безопасно ли… Что значит безопасно ?

По факту. Какой бы ты форум не читал, везде найдутся кто скажет «ЗА» и кто скажет «Против».

Ориентироваться на мнение одного, кого-то там, кто якобы «30 лет сидит и в ус не дует», я бы не стал.

Брать за ориентир фразу «многие промышленные решения», не понимая почему и как и зачем, ну…немного странно и не логично.

Все точки над И ставят бенчмарки под конкретную задачу/задачи. Почему ты их не смотришь ?

kambulya999
()

Как минимум ты должен понимать как она работает и что делать в случае чего Вряд ли ее можно советовать в качестве поставил и забыл. С ext4 ты размечаешь диск и просто забываешь, что у тебя существует какая-то там файловая система. Каждому свое.

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от Im_not_a_robot

С ext4 ты размечаешь диск и просто забываешь, что у тебя существует какая-то там файловая система.

Если не случилась неудача. Например, кончились иноды. Или в некоторых каталогах поиск файла занимает время существенно большее, чем ожидается.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)

Смотря где. Дома - btrfs лучшая. В продакшене - есть варианты.

Сжатие уже обсудили. Использую lzo на паре 2Гб жестких дисках в зеркале.

Еще полезнейшая фича - файловая система может размещаться на нескольких дисках. В зеркале или чередованием. Или ее можно просто увеличить, добавив еще диск-другуй. Никакого дедовского mdadm, никаких скачек по минным полям ZFS, мне нравится.

Советую полистать на досуге: https://wiki.archlinux.org/title/Btrfs_(Русский)

hargard ★★
()
Ответ на: комментарий от Im_not_a_robot

файловая система может размещаться на нескольких дисках. В зеркале или чередованием.

в зеркале

И если один из них навернется?

Сам как думаешь?

t184256 ★★★★★
()

Стабильная, пока оператива и процессор нормально работает.

У меня был случай потери все ФС из за кривого разгона процессора (данные при этом восстановились).

И когда «пробило» планку оперативной памяти (там и часть данных улетела).

И крайне не советую использовать раздел BtrFS одновременно из Линукса и Винды (через WinBtrFS). Если дуалбут. Порознь можно.

В остальном все норм.

Vochatrak-az-ezm ★★
()
Ответ на: комментарий от Im_not_a_robot

Вряд ли ее можно советовать в качестве поставил и забыл

В таком качестве весь Линуукс советовать не стоит, во всяком случае тем кто не понимает «как она работает и что делать в случае чего» (:

MrClon ★★★★★
()
Ответ на: комментарий от emorozov

Со сжатием можно вполне заниматься разработкой кучи проектов на ноуте с 256 Гб SSD, место не заканчивается никогда.

Сжатие почти не работает для самых объёмных файлов (фото, аудио, видео, архивы). С исходниками проектов работает, но они небольшие, для них очень важна скорость поиска по файлам и скорость компиляции. Так что их лучше не жать, особенно учитывая, что сейчас ssd недорогие.

Да, btrfs можно пользоваться. Но зачем, если есть ext4…

Aster
()
Ответ на: комментарий от Aster

Я не уверен, что есть хоть какое-то замедление из-за сжатия исходников. Наоборот, скорее всего, будет ускорение из-за уменьшения I/O.

Да, сжимаются не все файлы, но эффект всё же весьма значительный:

# compsize /var
Processed 12391128 files, 351387 regular extents (6823949 refs), 7304152 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       68%       27G          40G         443G
none       100%       16G          16G         111G
zstd        38%      8.1G          20G         328G
prealloc   100%      3.1G         3.1G         3.1G

Без сжатия мне уже пришлось бы покупать новый SSD или ноутбук.

emorozov
()

Вопрос знатокам и любителям.

Если отключить CoW ,например, на всю бд(/var/lib/mysql), то как будет по производительность по сравнению с xfs или etx4?

https://wiki.archlinux.org/title/btrfs#Disabling_CoW

permafrost ★★
()
Последнее исправление: permafrost (всего исправлений: 1)
Ответ на: комментарий от emorozov

Я тоже не технические причины имею в виду. То, что Red Hat ее дропнула – серьезная проблема. Они же не просто формально перестали поддерживать, они и в апстрим btrfs практически ничего не коммитят.

i586 ★★★★★
()
Ответ на: комментарий от emorozov

Я не уверен, что есть хоть какое-то замедление из-за сжатия исходников. Наоборот, скорее всего, будет ускорение из-за уменьшения I/O.

Не будет. Объем и структура исходников как правило такова, что файлы пишутся и читаются в один запрос и лежат в одном экстенте. Поэтому будет ли это read/write на 32KB или 16KB ничего не поменяет, ибо иопсы одни и те же

no-dashi-v2 ★★
()