LINUX.ORG.RU

BtrFS готова говорили они

 


0

2

Линукс начал через раз загружаться, я уж подумал что что-то спалил в экспериментах с видеокартой, а оказывается нет, виноват был BtrFS:

$ sudo btrfs check /dev/sda3
Opening filesystem to check...
Checking filesystem on /dev/sda3
UUID: 86945e7c-6b8c-45d4-a6f8-cd2a6d23c1d6
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 262 inode 266 errors 200, dir isize wrong
root 262 inode 16687041 errors 1, no inode item
	unresolved ref dir 266 index 7773 namelen 11 name kwinrc.lock filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16687043 errors 1, no inode item
	unresolved ref dir 266 index 7775 namelen 6 name kwinrc filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16687046 errors 1, no inode item
	unresolved ref dir 266 index 7778 namelen 18 name kglobalshortcutsrc filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16687047 errors 1, no inode item
	unresolved ref dir 266 index 7779 namelen 11 name kwinrc.lock filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16687059 errors 1, no inode item
	unresolved ref dir 266 index 7793 namelen 9 name dolphinrc filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16687070 errors 1, no inode item
	unresolved ref dir 266 index 7797 namelen 14 name dolphinrc.lock filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16690369 errors 1, no inode item
	unresolved ref dir 266 index 8473 namelen 11 name kwinrc.lock filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16690370 errors 1, no inode item
	unresolved ref dir 266 index 8475 namelen 6 name kwinrc filetype 1 errors 5, no dir item, no inode ref
root 262 inode 16690375 errors 1, no inode item
	unresolved ref dir 266 index 8479 namelen 11 name kwinrc.lock filetype 1 errors 5, no dir item, no inode ref
ERROR: errors found in fs roots
found 67286298624 bytes used, error(s) found
total csum bytes: 56626160
total tree bytes: 7056916480
total fs tree bytes: 6871351296
total extent tree bytes: 115212288
btree space waste bytes: 1063369100
file data blocks allocated: 102890029056
 referenced 69393457152

Как так? Вроде бы ничего особенного с системой не делал, жёстко не выключал кроме вышеуказынных случаев когда система виснет при загрузке. Какой ФС в Линуксе можно пользоваться чтобы было надёжно и ничего не ломалось, пусть и работает медленнее?

Уже файловая система BFS в Haiku получается надёжнее. В результате разных экспериментов и тестов драйверов у меня постоянно падает ядро и происходит жёсткая перезагрузка/выключение, а файловая система остаётся цела. Даже случайное монтирование BFS два раза в хост систему и виртуальную машину и запись в обе не привело к существенным проблемам в ФС.

btrfs check --repair вроде бы починил файловую систему.

Дистрибутив: openSUSE Tumbleweed.

★★★★★
Ответ на: комментарий от anonymous

Ну не сидеть же на ФС с фиксированным числом inode. Даже в DOS с FAT16 такого ограничения нет.

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

тебе шашечки или ехать? зато там есть data=journal

anonymous
()

Аварийного выключения не было? Что за модель диска?

mxfm ★★
()

Какой ФС в Линуксе можно пользоваться чтобы было надёжно и ничего не ломалось, пусть и работает медленнее?

ext4

Простой дефолтный вариант без выпендрёжа. Работает не так уж медленно.

А можно и чтобы ещё быстрее работало - ext2, оно без журнала но если не выключать неожиданно питание то не сломается.

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

У тебя они заканчивались когда-нить, кроме случаев когда отформатировал с нестандартным уменьшенным их количеством?

firkax ★★★★★
()

Да как вы умудряетесь её ломать? У меня уже пять лет на двух машинах пыхтит, включая умирающий ssd, у которого таблица разделов регулярно бьётся и приходится вручную восстанавливать. Но при этом btrfs жива.

btrfs check –repair

Ещё один. Это команда для убийства ФС. Тебе повезло, что после этого система загрузилась.

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

Это команда для убийства ФС.

В любом случае зависания при загрузке оно починило. Особо важных данных на этом разделе нет.

Как правильно чинить?

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

btrfs check –repair

Ещё один. Это команда для убийства ФС. Тебе повезло, что после этого система загрузилась.

отвергая предлагай.

Как вместо этого восстановить файловую систему?

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

А кому не нужен fsck?

Если пропало электричество и буфера не сбросились, то как восстановить систему?

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

Если пропало электричество и буфера не сбросились, то как восстановить систему?

Драйвер ФС автоматически откатывает незавершённый журнал при монтировании. В Haiku и Windows по крайней мере так.

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

В бородатом году на ext3 у меня как-то закончились inode - я пробовал юзать какую-то софтину для бекапа корня. Не представляю сколько там миллиардов файликов мелких за пару дней насобиралось, но факт - я не смог записывать на диск при наличии свободного места. Но это больше курьез и жж, нежели претензия к ext3.

ololoid ★★★★
()

Задрал уже спамить своей гайкой к месту и не к месту.

Какой ФС в Линуксе можно пользоваться чтобы было надёжно и ничего не ломалось,

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

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

Зависит от того как сломал.

Я откуда знаю? Специально я её не ломал. Вывод btrfs check в заглавном сообщении.

Я свою починил через btrfs rescue chunk-recover.

То есть у вас она тоже ломается.

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

Можно отключить журнал в ext4. ext2 не поддерживает экстенты

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

xfs иногда тоже глючит дай боже.

У меня даже глюк проявлялся с тем, что файловая система падает при 100% заполнении раздела.

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

То есть у вас она тоже ломается.

Вставил битую RAM память. Приложения падали, я перезагружал комп в надежде, что глюки исчезнут. На примерно четвёртый раз комп не загрузился, ругаясь на битый корень ФС.

Выкинул битую планку RAM и успешно починил ФС.

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

Драйвер ФС автоматически откатывает незавершённый журнал при монтировании. В Haiku и Windows по крайней мере так.

Что является быстрым режимом работы fsck прямо во время процедуры монтирования. Так в xfs сделано. Но там есть и жесткий репейр, когда все плохо.

А еще поэтому хайку никто не пользуется а в windows иногда раздел улетает в нирвану, что нет нормального fsck.

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

Доброе утро.

И вам здравствовать!

В норме журналируемым и CoW ФС не нужен fsck.

Это фигура речи. В норме никому не нужен fsck. На то она и норма. Просто в журналируемых ФС можно обойтись без запуска fsck, потому что проверка и откат журнала при мелких неполадках выполняется прямо вов время монтирования. Но в тяжелых случаях инструменты для разбора и проверки ФС все равно нужны.

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

Драйвер ФС автоматически откатывает незавершённый журнал при монтировании

Журнал нельзя откатить. Его можно только накатить. Всё потому что нет никакой информации о том, в каком состоянии были прерваны запись в основное хранилище. Часть может быть записана, часть нет. У записанной части потеряно предыдущее состояние. Нет никакой информации о том, какая часть не записана. Поэтому единственное разумное действие — раскатать содержимое журнала в основное хранилище.

i-rinat ★★★★★
()

Какой ФС в Линуксе можно пользоваться чтобы было надёжно и ничего не ломалось, пусть и работает медленнее?

Тут вопрос не столько какой, сколько как настраивал и эксплуатировал, ту же btrfs можно форматировать и монтировать с очень разными степенями надёжности.
(Я с ней обращаюсь правильно и по тому ей и доволен)

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

Что является быстрым режимом работы fsck прямо во время процедуры монтирования.

Нет же. Содержимое журнала по сути представляет собой набор инструкций вида «записать вот эти 4 кБ данных по смещению вот такому». Код драйвера файловой системы при монтировании проверяет, в каком состоянии журнал. Если там есть кучка неподтверждённых транзакций, все эти инструкции исполняются по очереди. Концептуально простая процедура, не требующая знаний о структурах данных файловой системы.

А вот для реализации fsck нужно детальное понимание способа хранения данных на накопителе.

i-rinat ★★★★★
()
Ответ на: комментарий от X512

не сидеть же на ФС с фиксированным числом inode

ReiserFS 3. Причём это еще и самая надёжная и быстрая (при работе с большим количеством мелких файлов) линуксовая ФС.

Единсвенный минус — нет автоматического TRIM. Т. е. на тех SSD, где это реально нужно, придётся настраивать TRIM отмонтированного раздела через hdparm+wiper.sh.

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

новых разработчиков нашли или всё заброшено?

Только поддержка есть и патчи прилетают. А вот, чтобы именно развитие ФС — такого нет.

В любом случае мне пока функциональности ReiserFS более чем достаточно, а снимками ФС я не пользуюсь.

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

Для Raiser3 нужно в опциях монтирования нужно notail прописать. Иначе через несколько месяцев начинаются неконтролируемые зависания, очень похожие на 12309 (но не он). Хз что там накапливается. Могу сбросить линк на свою историю любви с этим эффектом.

А в остальном ФС отличная. Я даже сейчас ее использую иногда. И могу рекомендовать.

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

Ну или можешь к культу ZFS присоединиться — они вон мамой клянутся, что у них-то ФС точно безбажная.

Как официальный представитель культа ZFS на этом форуме заявляю, что баги есть, но они далеко не такие детские, как у Btrfs… которые за десять лет (ДЕСЯТЬ, Карл! а то и больше, не считал), до сих пор так и не пофиксили!

В ZFS scrub находит скрытые ошибки; в Btrfs scrub добивает пул до невосстанавливаемого состояния. Это нормально, как считаешь? ☺

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

По ссылке - инфа от мошенника, у которого fsck «кушает детей». Задрали вместе с дядюшкой Тс’о ныть про то, как Red Hat-у не хватает денег на нормальных разработчиков.

anonymous
()

Надёжнее ext4, только ReiserFS 3 :-)))

BtrFS готова говорили они

Кто говорил? Сколько она в релизе, столько я слышу, что с ней постоянные проблемы.

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

в арче проблем с ней нет, так как всегда последняя версия, а не патченное говно

tz4678 ★★
()

btrfs check –repair

Ещё один. Это команда для убийства ФС. Тебе повезло, что после этого система загрузилась.

Напомнило чегой-то - https://www.youtube.com/watch?v=qn0XmoE-UNE

У меня btrfs больше года под гентой стояла и все ок было. вообще единственная фс, которая у меня ломалась, это была jfs много лет назад, корень перестал монтироваться и усе. может диск тютю?

Keltir
()
Последнее исправление: Keltir (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Код драйвера файловой системы при монтировании проверяет, в каком состоянии журнал

А вот для реализации fsck нужно детальное понимание способа хранения данных на накопителе.

Мосье не в курсе, что fsck с успехом делает journal replay, и думал, что это привилегия лишь драйвера ФС?А вот для реализации fsck нужно детальное понимание способа хранения данных на накопителе.

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

Ну не сидеть же на ФС с фиксированным числом inode.

А что в этом такого плохого ? Надо просто bytes-per-inode ratio выбирать правильно. В любом случае таблички с inode’ами не занимают как-то особо много места. В ФС с динамическими inode’ами они ведь не в астрале хранятся, а тоже занимают место при появлении новых файлов.

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

Многие проигнорировали наличие в ядре JFS. Между тем она меня поразила и скоростью (на диске), и бронебойностью. Минус, который меня сильно не задел - отсутствие дефрагментатора. Стояла у жены долгое время, а там выключение происходило выдергиванием из розетки. Без проблем вообще. ZFS гениальная, записывайте в сектанты. Но с серьезным минусом, что забивать диск полностью лучше не пробовать. Если нужно просто воткнуть и без головняка - ext4. У меня самого BTRFS достаточно много. Без повода не ломается. XFS теперь начали усиленно пилить, даже что-то вроде CoW теперь там есть. Это пугает.

olegon-ru
()
Ответ на: комментарий от DawnCaster

В ФС с динамическими inode’ами

В этом плане NTFS веселая… Она под $MFT место занимает, но не отдает :) Ради эксперимента делал пустой, но заполненный на 100% диск. Делаешь несколько миллионов файликов нулевой длины, а потом их удаляешь.

olegon-ru
()
Ответ на: комментарий от anonymous

По ссылке - инфа от мошенника

от мошенника

Сильно сказано. Пруфы будут?

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

Это команда для убийства ФС. Тебе повезло, что после этого система загрузилась.

До чего же интересная у Btrfs экосистема. Одни строят, другие едят детей… :)

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

Мосье не в курсе, что fsck с успехом делает journal replay, и думал, что это привилегия лишь драйвера ФС?

Грязные инсинуации.

i-rinat ★★★★★
()
Ответ на: комментарий от Keltir

я на btrfs года три как. сама система не отказывала, но что-то было критичное, связанное с деградацией производительности, которое тут же исправили. zfs, возможно, и лучше, но его нет в ядре, а значит, что при разработке ядра на какие-то глюки в zfs никто не будет обращать внимания.

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

я бы из недостатков btrfs отметил, что с ней не особо дружит с mysql и другими базами (chattr +C на каталоге с данными делаем), тож самое касается логов, образов виртуальных дисков, где данные мелкими чанками пишутся. ну и еще у меня хоть и сжатие включено, но от него особо толку нету:

➜ sudo compsize /home   

Processed 24610153 files, 561004 regular extents (11603306 refs), 14320010 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       95%       71G          74G         1.2T       
none       100%       69G          69G         1.1T       
zlib        38%      1.2G         3.0G         3.0G       
lzo         52%      621M         1.1G          30G       
zstd        43%      645M         1.4G          21G       
prealloc   100%       38M          38M         849M

По-умолчанию zstd:3 вроде используется, если это поведение не изменили.

tz4678 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.