Комментарии 31
btrfs
Отказоустойчивая
Смешно.
А что не так? То что она альфа, ещё не означает что она неюзабельна.
Если на то пошло, можно пальцем ткнуть в недавнюю ошибку в коде ядра и ext4 из-за которой, она в определённых ситуациях сжирала данные.
Если на то пошло, можно пальцем ткнуть в недавнюю ошибку в коде ядра и ext4 из-за которой, она в определённых ситуациях сжирала данные.
А можно пальцем ткнуть в давнишнее письмо Эдика Шишкина в lkml, где он на пальцах расписывает, почему btrfs — defective by design и не взлетит.
И там же Крис расписал вариант решения проблемы и говорит о фиксе. А как там у Эдика Шишкина дела с reiser4? Что-то после многих текстов о превосходстве reiser4 и обещаний интеграции в mainline давно ничего не слышно.
Спасибо, я отлично помню это сообщение. Но в данный момент, я не вижу под linux ни одной замены поставляемой нативно.
Да есть Reiser4. Она умеет упаковывать мелкие данные данные в большой блок, это огромный плюс. Так же её не обделили модульностью и возможностью включения прозрачного сжатия.
Но её некому поддерживать и насколько я понимаю, для её использования мне нужно прикручивать старое ядро и накладывать патчи.
ZFS, о ней я знаю намного меньше, но насколько я помню, там механизмы снапшотов реализованы совершенно иначе. Насколько я помню, она разрабатывалась под Solaris, т.е. её тоже надо прикручивать. Хотя почитав wiki, выяснил что делается это установкой её из репозитория.
Я с удовольствием сменю btrfs, на другую файловую систему, если в ней будут:
1. Сжатие данных.
2. CoW
3. Выравнивание износа ячеек ssd, как на btrfs, например с ключём монтирования ssd_spread.
4. Упаковка мелких файлов в tails, хотя насколько я помню, она ещё не реализована.
5. Снапшоты и сабволумы, т.к. с ними намного удобней оперировать, чем с разделами на диске.
Я хочу сказать, что я не против других файловых систем, просто пока я не вижу альтернативы и буду очень признателен если мне её покажут.
Да есть Reiser4. Она умеет упаковывать мелкие данные данные в большой блок, это огромный плюс. Так же её не обделили модульностью и возможностью включения прозрачного сжатия.
Но её некому поддерживать и насколько я понимаю, для её использования мне нужно прикручивать старое ядро и накладывать патчи.
ZFS, о ней я знаю намного меньше, но насколько я помню, там механизмы снапшотов реализованы совершенно иначе. Насколько я помню, она разрабатывалась под Solaris, т.е. её тоже надо прикручивать. Хотя почитав wiki, выяснил что делается это установкой её из репозитория.
Я с удовольствием сменю btrfs, на другую файловую систему, если в ней будут:
1. Сжатие данных.
2. CoW
3. Выравнивание износа ячеек ssd, как на btrfs, например с ключём монтирования ssd_spread.
4. Упаковка мелких файлов в tails, хотя насколько я помню, она ещё не реализована.
5. Снапшоты и сабволумы, т.к. с ними намного удобней оперировать, чем с разделами на диске.
Я хочу сказать, что я не против других файловых систем, просто пока я не вижу альтернативы и буду очень признателен если мне её покажут.
С таким списком требований, а особенно
Снапшоты и сабволумы… только zfs (вроде есть нативный модуль ядра для неё). Хотя чёрт её знает, как zfs на ssd будет себя вести.
Кхм. ZFS подходит, только по одному пункту, остальные же:
прозрачное сжатие к ней можно прикрутить.
CoW только подобие, при постоянном создании снапшотов, т.к. старые данные, не будут перезаписываться.
Выравнивания износа нету, упаковки мелких файлов нету.
У ZFS нету квот как в btrfs и ntfs (мне не принципиально, но факт), которые или в 3.6 или в 3.7 реализуют в btrfs.
Переменный размер блоков это добро, его очень часто не хватает, но учитывая экценты в btrfs, размер блоков не имеет большого значения.
Из письма шишкина, кстати, ясно только то, что ему не нравиться дизайн, файловой системы. Точнее то что в ней под всё есть «Дерево», даже под логи, метаданные и кеш суммы (отдельное под данные). (Да на практике какой-то куст).
Как я понял, то по каким то причинам, дерево ещё у btrfs любит перестраиваться, это похоже и есть её дырка в отказоустойчивости. Но если включёны снапшоты, то повреждённое дерево оно восстанавливает из них.
Проблема при работе с большим количеством мелких файлов. Да, есть такая проблема, btrfs искажает данные о свободной памяти и не эффективно использует место при большом количестве мелких файлов.
НО, господин Шишкин, я не видел другой FS с tail packing, кроме reizer, не одна не умеет потенциально удачно с ними работать, кроме Raiser4.
Вообще надо понимать, что btrfs с Reiser4, сравнивать не корректно, в виду того, что единственное что их объединяет это B-trees. Остальное у них различно. Raiser, работает с диском. Btrfs работает с размеченными чанками. Как следствие даже не пытается использовать размеченные под её террабайты, пока чанк не заполняться информацией и не будет создан новый чанк и так до забивания раздела под завязку.
Извините, если получилось агрессивно и сумбурно. Я просто сам путаюсь уже во всех этих тонкостях.
прозрачное сжатие к ней можно прикрутить.
CoW только подобие, при постоянном создании снапшотов, т.к. старые данные, не будут перезаписываться.
Выравнивания износа нету, упаковки мелких файлов нету.
У ZFS нету квот как в btrfs и ntfs (мне не принципиально, но факт), которые или в 3.6 или в 3.7 реализуют в btrfs.
Переменный размер блоков это добро, его очень часто не хватает, но учитывая экценты в btrfs, размер блоков не имеет большого значения.
Из письма шишкина, кстати, ясно только то, что ему не нравиться дизайн, файловой системы. Точнее то что в ней под всё есть «Дерево», даже под логи, метаданные и кеш суммы (отдельное под данные). (Да на практике какой-то куст).
Как я понял, то по каким то причинам, дерево ещё у btrfs любит перестраиваться, это похоже и есть её дырка в отказоустойчивости. Но если включёны снапшоты, то повреждённое дерево оно восстанавливает из них.
Проблема при работе с большим количеством мелких файлов. Да, есть такая проблема, btrfs искажает данные о свободной памяти и не эффективно использует место при большом количестве мелких файлов.
НО, господин Шишкин, я не видел другой FS с tail packing, кроме reizer, не одна не умеет потенциально удачно с ними работать, кроме Raiser4.
Вообще надо понимать, что btrfs с Reiser4, сравнивать не корректно, в виду того, что единственное что их объединяет это B-trees. Остальное у них различно. Raiser, работает с диском. Btrfs работает с размеченными чанками. Как следствие даже не пытается использовать размеченные под её террабайты, пока чанк не заполняться информацией и не будет создан новый чанк и так до забивания раздела под завязку.
Извините, если получилось агрессивно и сумбурно. Я просто сам путаюсь уже во всех этих тонкостях.
Из письма шишкина, кстати, ясно только то, что ему не нравиться дизайн, файловой системы.Он, как я понял, упирает на то, что B-trees работают так, как задумывалось, с приемлемыми аналитически посчитанными вычислительными сложностями операций, если у них листы постоянного размера, а разработчики btrfs ничтоже сумняшеся запихали туда информацию переменного размера (те самые inline extents), и поэтому оно работает совсем не так, как должно.
я не видел другой FS с tail packing, кроме reizer, не одна не умеет потенциально удачно с ними работать, кроме Raiser4.Reiser3 вроде как умеет. На своём опыте: gentoo'вский portage с portage tree, размещённым на reiser3, шевелится в разы быстрее, чем на ext.
Извините, если получилось агрессивно и сумбурно. Я просто сам путаюсь уже во всех этих тонкостях.Да нормально. Мне тоже хочется, чтобы всё и сразу, но так не бывает, вот и сижу на дефолтной ext4.
Ext4 является чем то средним, в этом её большой жирный плюс.
Я очень хочу узнать, почему вы хотите выравнивать износ на ssd-дисках вместо прошивки ssd диска. Вы думаете, btrfs с этим справится лучше?
Да я думаю btrfs справиться с этим лучше, я примерно представляю как она работает, пусть и не уверен что правильно.
Прошивка стоит официальная и последняя, но как работает она я смутно предполагаю. Если она работает хорошо, то btrfs, со своей принудительной фрагментацией и принудительной записью только в не использованные ранее блоки ничем ей не помешает.
Прошивка стоит официальная и последняя, но как работает она я смутно предполагаю. Если она работает хорошо, то btrfs, со своей принудительной фрагментацией и принудительной записью только в не использованные ранее блоки ничем ей не помешает.
Помешать не помешает, а производительность уронит. Практически все ssd, кроме совсем топовых (типа 900ой серии интела) очень не любят произвольную запись мелкими блоками.
А как же принудительный write cache?
Мы про производительность записи на SSD в зависимости от того, линейно или рандомно на неё пишет файловая система, или про производительность фс?
ssd учитывая почти нулевую задержку и write cache с редко сбрасываемыми, но объёмными «грязными» данными, получается не будет работать с постоянными мелкими запросами, разве не так?
Насколько я помню, у них производительность при совсем случайной записи в больших объёмах падает раза в 2, но разница между 500 и 300 Мб/с на десктопе или ноуте не должна быть заметна.
Насколько я помню, у них производительность при совсем случайной записи в больших объёмах падает раза в 2, но разница между 500 и 300 Мб/с на десктопе или ноуте не должна быть заметна.
Я как-то в режиме broad search поднял btrfs для cephs. Оно прожило примерно 10 минут, после чего снесло нафиг ядро из-за ошибки где-то в недрах btrfs. Ничего особенного, просто random io.
find /tmp/system/snapshots/ -mtime +7 -delete
Удалит файлы, которым больше 7 дней.
При чём тут /var/tmp?
Если вы по поводу логов, то не вижу смысла, он заново копируется из раздела, перед отмонтированием, если про автоматическое монтирование, отмонтирование, то в любом случае, папка создаётся и удаляется в процессе загрузки.
Что вы предлагаете хранить между перезагрузками?
Если вы по поводу логов, то не вижу смысла, он заново копируется из раздела, перед отмонтированием, если про автоматическое монтирование, отмонтирование, то в любом случае, папка создаётся и удаляется в процессе загрузки.
Что вы предлагаете хранить между перезагрузками?
Да, тут уже неважно где и что создаётся :) Обо всём говорит качество самого скрипта.
а если /tmp/system — это файл или сокет или что-то ещё, то мы всё равно будем пытаться создать какую-то директорию? И после того как не получится создать, попытаемся примонтировать туда девайс. И даже когда монтирование отвалится, то мы всё равно будем пытаться туда заснэпшотиться.
Ну и создание директории для снэпшотав тоже интересное :) На системе, где в /tmp никогда не будет выживать директория system, мы никогда не создадим директорию для снэпшотов.
Предположим дошли до монтирования, но монтирование отвалилось, а мы всё равно настойчиво пытаемся сделать снэпшот. А на многих дистрах /tmp сейчас в tmpfs ;)
Вобщем какой-то неотказоустойчивый скрипт для отказоустойчивой системы :)
if [ ! -d /tmp/system/ ]
then
mkdir /tmp/system/
else if [ ! -d /tmp/system/snapshots/ ]
then
mkdir /tmp/system/snapshots/
fi
fi
а если /tmp/system — это файл или сокет или что-то ещё, то мы всё равно будем пытаться создать какую-то директорию? И после того как не получится создать, попытаемся примонтировать туда девайс. И даже когда монтирование отвалится, то мы всё равно будем пытаться туда заснэпшотиться.
Ну и создание директории для снэпшотав тоже интересное :) На системе, где в /tmp никогда не будет выживать директория system, мы никогда не создадим директорию для снэпшотов.
mount /dev/sda2 /tmp/system/
Предположим дошли до монтирования, но монтирование отвалилось, а мы всё равно настойчиво пытаемся сделать снэпшот. А на многих дистрах /tmp сейчас в tmpfs ;)
Вобщем какой-то неотказоустойчивый скрипт для отказоустойчивой системы :)
Да признаюсь, есть доля идиотизма. Но я лично не сталкивался с дистрами с /tmp, в tmpfs, хотя сам тоже монтирую tmp в оперативную память.
Фокус в том, что скрипт иногда не верно отрабатывал и если tmp, подмонтирована не в оперативку, то в результате, даже после перезагрузки папки system, могли оставаться.
Я сильно сомневаюсь что в /tmp будет сокет или файл, с таким именем. Но да, замечание справедливо, сейчас подумаю как исправить.
Фокус в том, что скрипт иногда не верно отрабатывал и если tmp, подмонтирована не в оперативку, то в результате, даже после перезагрузки папки system, могли оставаться.
Я сильно сомневаюсь что в /tmp будет сокет или файл, с таким именем. Но да, замечание справедливо, сейчас подумаю как исправить.
Вот только хотел сообразить статью на эту тему, тоже как-то посмотрел в сторону btrfs. Ещё была мысль сделать raid1 c разделом другого диска, btrfs позволяет это делать очень просто, тогда мы получаем и избыточность, и возможность делать откат системы. Беспроигрышный вариант.
К стати, неплохо было бы добавить в статью, что subvolume можно не только заменить, но и подмонтировать в любую папку, и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС. По структуре хранения всё это напоминает мне git, но можно удалить коммиты.
К стати, неплохо было бы добавить в статью, что subvolume можно не только заменить, но и подмонтировать в любую папку, и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС. По структуре хранения всё это напоминает мне git, но можно удалить коммиты.
По поводу RAID, тоже размышлял. Но в ноутбуке, такое достаточно трудно осуществимо.
Да, действительно можно было бы добавить, но учитывая энтропию имён снапшотов и папок к ним, это неудобно (открывать лог и вбивать в консоли длинный параметр монтирования) осуществимо без подмонтирования и просмотра раздела в целом.
А вот, по по поводу «и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС.», упомяну. Так как это действительно легко осуществимо и я просто не сообразил, о таком раскладе событий.
Да, действительно можно было бы добавить, но учитывая энтропию имён снапшотов и папок к ним, это неудобно (открывать лог и вбивать в консоли длинный параметр монтирования) осуществимо без подмонтирования и просмотра раздела в целом.
А вот, по по поводу «и достать несколько файлов из любого бекапа, не трогая текущее состояние ФС.», упомяну. Так как это действительно легко осуществимо и я просто не сообразил, о таком раскладе событий.
UPD 2: ...
Ну не совсем и поправил :)
Воткни вначале set -e, чтобы при падении любой из команд всё останавливалось, а если вдруг нужно будет пропустить падение какой-либо из команд, то достаточно будет сделать command || /bin/true
Директорию со снэпшотами нужно создавать после монтирования.
И если делаешь скрипты для запуска вручную, то желатально ещё использовать Bash Traps и снимать монтирование итп в их обработчиках, тк Ctrl-C достаточно часто жмут.
Наверное, лучше всё-таки /home выделять на отдельный раздел, чем думать о нём при откатах
Когда у тебя ssd, при условии что я не параноик, хочется равномерного износа. Потому даже вынос boot, на отдельный раздел, это уже не равномерный износ. Представь что если вынести home?
Учитывая, то что все папки с постоянно изменяющимися и не важными файлами у меня в tmpfs, то система почти не пишет на ssd, но я то пишу, я же пользуюсь home, гугл хром, пишет почти ежесекундно, со скоростью 160 кб/с.
Вот такая вот противная «шляпа», а так да, home достаточно удобно выносить на отдельный раздел.
Учитывая, то что все папки с постоянно изменяющимися и не важными файлами у меня в tmpfs, то система почти не пишет на ssd, но я то пишу, я же пользуюсь home, гугл хром, пишет почти ежесекундно, со скоростью 160 кб/с.
Вот такая вот противная «шляпа», а так да, home достаточно удобно выносить на отдельный раздел.
Все время ставлю btrfs и все время оно валит мне ядро. Сыровато.
Очень интересно, а чуть более развёрнуто?
Ни разу не возникало проблем, даже при установке /boot на btrfs.
(Да, груб 2 и он выдавал ошибку, но это он виноват, а не фс и это легко исправляется комментом 1 строки)
Ни разу не возникало проблем, даже при установке /boot на btrfs.
(Да, груб 2 и он выдавал ошибку, но это он виноват, а не фс и это легко исправляется комментом 1 строки)
Мы экспериментируем с ceph на debian squeeze c ядром Linux 2.6.32-16-pve #1 SMP Fri Nov 9 11:42:51 CET 2012 x86_64 GNU/Linux. Это последний proxmox из коробки.
Там можно под ceph osd отдать raw device, заформаченый в btrfs. Когда мы так делаем, система в итоге колтрейсится и паникует.
Причем если выдать партицию на диске, то вроде все нормально. Проблема проявляется, когда /dev/sda, например, целиком делается btrfs и маунтится. Там что-то с btrfs check связано, который not taunted.
Там можно под ceph osd отдать raw device, заформаченый в btrfs. Когда мы так делаем, система в итоге колтрейсится и паникует.
Причем если выдать партицию на диске, то вроде все нормально. Проблема проявляется, когда /dev/sda, например, целиком делается btrfs и маунтится. Там что-то с btrfs check связано, который not taunted.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Отказоустойчивая» система на базе Ubuntu и btrfs