Comments 28
На лаптопе использую btrfs для корня и xfs для накопителя с мультимедийными файлами, работает очень даже неплохо.
Фейсбук использует btrfs? Занятно, но больше на рядовое официальное мероприятие смахивает, если честно.
Фейсбук использует btrfs? Занятно, но больше на рядовое официальное мероприятие смахивает, если честно.
При последней глобальной смене железа и ОС все никак не мог решиться, какую ФС поставить. В итоге остановился на классике — ext2 для загрузочной области и ext4. Не смог найти аргументов в пользу btrfs для лаптопа, если честно =)
Да, это не знаковое мероприятие, скорее посиделки с плюшками, где обсудили как дела друг у друга.
Да, это не знаковое мероприятие, скорее посиделки с плюшками, где обсудили как дела друг у друга.
btrfs интересная система, но для рядового использования избыточна. Я тоже предпочитаю ext4, стабильно, надёжно.
способ убить ext4 за пару минут: загрузиться в виртуальную машину с доступом к физическому диску с того же раздела.
ext3 как-то понадежнее к таким шуткам была.
ext3 как-то понадежнее к таким шуткам была.
Странный вывод о ненадежности ФС.
С тем же успехом можно в произвольное место тома записать мегабайт нулей, и удивиться, что все умерло.
Реальные ФС не проектируют на отказоустойчивость к таким шуткам.
С тем же успехом можно в произвольное место тома записать мегабайт нулей, и удивиться, что все умерло.
Реальные ФС не проектируют на отказоустойчивость к таким шуткам.
Могу подсказать способ, как убить любую ФС за пару секунд.
Я о том, что это не проблема ФС, а софта или пользователя.
Я о том, что это не проблема ФС, а софта или пользователя.
btrfs для лэптопа хороша снэпшотами.
Например, можно создать снэпшот корня, обновится и в случае кривого обновления легко вернуть систему в нормальное состояние.
Или же автоснэпшоты /home раз в 5 минут с автоочисткой в фоне устаревших — отлично спасет при случайной перезаписи / удалении файла.
Например, можно создать снэпшот корня, обновится и в случае кривого обновления легко вернуть систему в нормальное состояние.
Или же автоснэпшоты /home раз в 5 минут с автоочисткой в фоне устаревших — отлично спасет при случайной перезаписи / удалении файла.
Мне хотелось побаловаться со снапшотами и действительно, штука очень удобная. Для boot партиции у меня тоже ext2 был раньше, но сейчас из-за UEFI, в vfat пришлось форматировать.
btrfs для (моего) лаптопа хороша снапшотами и subvolume'ами с квотированием.
У меня вместо разделов сделан один большой btrfs, в котором /, /usr, /home, /var и ещё кое-что по мелочи сделано через subvolume, а размер замечательно регулируется квотами.
В рамках ограниченного хранилища — крайне удобно. gpt-разделы так не подвигаешь.
Ещё очень крутая штука с subvolume'ами это удаление директории с большим количеством мелких файлов внутри. То, что раньше приходилось делать через mv buildroot _removal; rm -rf _removal & mkdir buildroot, теперь просто делается через btrfs subvolume delete.
Ещё с ней хорошо работает docker и есть сжатие, которое для текстов (сорцов, например), весьма неплохо работает.
У меня вместо разделов сделан один большой btrfs, в котором /, /usr, /home, /var и ещё кое-что по мелочи сделано через subvolume, а размер замечательно регулируется квотами.
В рамках ограниченного хранилища — крайне удобно. gpt-разделы так не подвигаешь.
Ещё очень крутая штука с subvolume'ами это удаление директории с большим количеством мелких файлов внутри. То, что раньше приходилось делать через mv buildroot _removal; rm -rf _removal & mkdir buildroot, теперь просто делается через btrfs subvolume delete.
Ещё с ней хорошо работает docker и есть сжатие, которое для текстов (сорцов, например), весьма неплохо работает.
Использую btrfs на ноуте тоже. Удобно делать резервные копии при помощи snapshot и btrfs-send. Но при случайных выключениях (из-за ошибки в видеодрайвере ноут иногда зависал), появлялись неудаляемые каталоги. При попытке их вылечить, btrfsck вылетал с Segmentation Fault. Жутковато… И не верится, что в FB используют код такого низкого качества. Наверное, у них собственный форк, запатченный по самое не могу.
Вовсе необязательно при зависаниях видеодрайвера отключать питание, обычно это лечится магической клавишей SysRq.
Угу, у меня Lenovo T440s без клавиши SysRq. Точнее, она эмулируется нажатием Fn-S, но у меня эта эмуляция почему-то не работает.
Работа на *буках обычно производится нажатием без кнопки Fn клавиши печати экрана. Попробуйте перейти в терминал по Ctrl+Alt-F1, и нажать Alt+Shift+PrintScreen+h — если все хорошо, у вас должен вывалится help по клавише в stdout.
Так же не забывайте, что, по-крайней мере, в *buntu ее функционал по максимуму урезан из соображений безопасности; для повышения возможностей там надо редактировать файл /etc/sysctl.d/10-magic-sysrq.conf
У меня тоже есть бук от Леново, и клаву на нем тоже делали люди, явно умом обделенные. Мало того, что они зачем-то для SysRq поставили клавиши Fn, хотя можно было просто оставить на шифте — так они еще и додумались поменять Ctrl с Fn. Когда я на нем работал, мне пришлось выдрать клавишу Fn, чтобы каждый раз, когда я тянусь нажать Ctrl, я натыкался на резинку, и вспоминал, что Ctrl правее.
Так же не забывайте, что, по-крайней мере, в *buntu ее функционал по максимуму урезан из соображений безопасности; для повышения возможностей там надо редактировать файл /etc/sysctl.d/10-magic-sysrq.conf
У меня тоже есть бук от Леново, и клаву на нем тоже делали люди, явно умом обделенные. Мало того, что они зачем-то для SysRq поставили клавиши Fn, хотя можно было просто оставить на шифте — так они еще и додумались поменять Ctrl с Fn. Когда я на нем работал, мне пришлось выдрать клавишу Fn, чтобы каждый раз, когда я тянусь нажать Ctrl, я натыкался на резинку, и вспоминал, что Ctrl правее.
Lenovo очень давно добавила возможность менять Ctrl и Fn местами в биосе. Либо у Вас такой старый ноут, либо…
Lenovo 3000 G410. Не уверен, какого он года выпуска, но я его покупал лет 5-6 назад… И да, в нем нет такой опции. К тому же формат фактор у клавиш Ctrl и Fn на этом ноутбуке разный, так что, даже если добавят в биос, поменять надписи не выйдет. Но я, наверное, придираюсь — пусть уж хоть как-нибудь работает.
Пока удавалось избегать полного зависания, но глюки часто бывали с примонтированным по davfs Яндекс-Диском — зависал rsync и не убивался никак. Однако, затрудняюсь однозначно связать это с btrfs.
Раньше успользовал на старом лаптопе ext4 и однажды после зависания файлуха попортилась. Уже потом ext4 стабильнее стала.
Раньше успользовал на старом лаптопе ext4 и однажды после зависания файлуха попортилась. Уже потом ext4 стабильнее стала.
UFO just landed and posted this here
Использую на работа ceph fs. Очень удобно, практично, безопасно и гибко.
Удобно использовать в связке со slurm.
Удобно использовать в связке со slurm.
А можно чуть поподробнее, в чем удобство?
И в чем безопасность? На хабре много народу в комментах писало при глюки ceph и про его легкую убиваемость. Пожалуй первое прям такое положительное мнение без ругани, хотелось бы поподробнее.
Использую btrfs как основную на рабочем компе + ноуте пару лет. В целом, работает неплохо. Особенно интересны subvolumes и ro/rw снапшоты.
Но один раз btrfs полностью сдохла. До сих пор держу копию в надежде вытянуть из нее не успевшее сложиться в бекап ;)
И еще есть косяк с systemd+btrfs+luks rootfs — это просто не работает (но один раз из 20 можно загрузиться). Не может найти файловую систему — долго рассказывать, но в 2014-м этот баг не вылечили, пришлось назад на sysvinit уйти и потребности в systemd нет, поэтому не знаю, может уже и вылечили.
Но один раз btrfs полностью сдохла. До сих пор держу копию в надежде вытянуть из нее не успевшее сложиться в бекап ;)
И еще есть косяк с systemd+btrfs+luks rootfs — это просто не работает (но один раз из 20 можно загрузиться). Не может найти файловую систему — долго рассказывать, но в 2014-м этот баг не вылечили, пришлось назад на sysvinit уйти и потребности в systemd нет, поэтому не знаю, может уже и вылечили.
Касательно btrfs, может у Facebook'а с его армией программистов низкого уровня и живёт это как-то, но мне кажутся полными камикадзами те, кто пытаются тащить в продакшн файловую систему к которой физически не существует полноценного инструментария для восстановления, с единственным аргументом «да она практически не ломается»… Ломается и ещё как ломается.
И даже не обязательно до потери данных, есть, например такие ошибки, когда найдены чексумы на не существующие данные и инструменты не позволяют изменять файловую систему (отрубаются все возможности по shrink, работе с субтомами и т.д.) и сделать можно ровным счётом ни-че-го. Только бэкап данных --> снос раздела --> восстановление данных на вновь созданный раздел.
И коллектив разработчиков из «гениев», которые лепят ошибки, делают неполноценные фичи, ломающие работающий функционал и потом отмазывающиеся ответами типа «а ну это у нас в версии такой-то баг был, что у вас всё слетело кхерям, но уже исправили» или «ах, а мы и не знали, что новая фича ломает старую». И ладно бы эти косяки попадали только в unstable — в обычном ubuntu со стабильными ядрами такое возникает регулярно — просто потому, что, оказывается, вот таким вот специфическим функционалом файловой системы не многие пользуются и не отловили.
Отсутствие документации на функции и вообще невнятность работы некоторых функций тоже доставляют. До ядра 3.17 при исполнении btrfs check --init-csum-tree с описанием мол «перестраивает дерево чексумм», на деле просто сносило к чёрту дерево чексум и делало файловую систему не читаемой. Потом кто-то в мэйллисте на это тыкнул с вопросом «а нахрена это надо?» И получил ответ типа «а ну не нужно ей пользоваться она ещё не дописана, чтоб реально работала». А добавили так, просто, как кнопку «харакири», только под надписью «реанимация».
В общем, впечатление мрачное не столько от того, что файловая система чудовищно сырая (это-то как раз понятно и простительно), но от отношения разработчиков к процессу разработки и, в частности, к безопасности. По мне, так разработку нужно начинать с методов восстановления целостности файловой системы и данных и не выпускать ни единого стабильного релиза без полной их реализации, а не то, как это делают разработчики btrfs.
И даже не обязательно до потери данных, есть, например такие ошибки, когда найдены чексумы на не существующие данные и инструменты не позволяют изменять файловую систему (отрубаются все возможности по shrink, работе с субтомами и т.д.) и сделать можно ровным счётом ни-че-го. Только бэкап данных --> снос раздела --> восстановление данных на вновь созданный раздел.
И коллектив разработчиков из «гениев», которые лепят ошибки, делают неполноценные фичи, ломающие работающий функционал и потом отмазывающиеся ответами типа «а ну это у нас в версии такой-то баг был, что у вас всё слетело кхерям, но уже исправили» или «ах, а мы и не знали, что новая фича ломает старую». И ладно бы эти косяки попадали только в unstable — в обычном ubuntu со стабильными ядрами такое возникает регулярно — просто потому, что, оказывается, вот таким вот специфическим функционалом файловой системы не многие пользуются и не отловили.
Отсутствие документации на функции и вообще невнятность работы некоторых функций тоже доставляют. До ядра 3.17 при исполнении btrfs check --init-csum-tree с описанием мол «перестраивает дерево чексумм», на деле просто сносило к чёрту дерево чексум и делало файловую систему не читаемой. Потом кто-то в мэйллисте на это тыкнул с вопросом «а нахрена это надо?» И получил ответ типа «а ну не нужно ей пользоваться она ещё не дописана, чтоб реально работала». А добавили так, просто, как кнопку «харакири», только под надписью «реанимация».
В общем, впечатление мрачное не столько от того, что файловая система чудовищно сырая (это-то как раз понятно и простительно), но от отношения разработчиков к процессу разработки и, в частности, к безопасности. По мне, так разработку нужно начинать с методов восстановления целостности файловой системы и данных и не выпускать ни единого стабильного релиза без полной их реализации, а не то, как это делают разработчики btrfs.
Соглашусь. Моя домашняя система стоит на btrfs, плюс внешний диск на нем же. Качество работы отвратительное — очень часто бывает, что раздел внешнего диска отваливается, и либо α) не монтируется обратно, с какой-то ошибкой чтения (причем второй раздел на нем, *не-btrfs*, работает великолепно, то есть проблема не в диске) до — sick! — полной перезагрузки системы (поверхностное расследование причин не дало никаких результатов), либо β) монтируется без проблем, но… часть файлов отсутствует! То есть они физически есть, и путем магических манипуляций с перемонтированием системы они возвращаются на место, но это происходит далеко не сразу.
Что да самой системы, то ее загрузка часто виснет на «scanning for btrfs filesystems».
Я могу предположить, что проблемы решены в последних драйверах, у меня все-таки LTS-релиз, наверное в последних версиях софта и ядер много баг-фиксов, и все работает намного стабильнее. Так же предполагаю, что зависание на «scanning for…» может быть связано с очень убитым ноутом. Но все же я думаю, что когда буду вновь форматировать разделы, например после покупки десктопа — к черту эту btrfs, уж лучше поставлю старую надежную ext4.
Что да самой системы, то ее загрузка часто виснет на «scanning for btrfs filesystems».
Я могу предположить, что проблемы решены в последних драйверах, у меня все-таки LTS-релиз, наверное в последних версиях софта и ядер много баг-фиксов, и все работает намного стабильнее. Так же предполагаю, что зависание на «scanning for…» может быть связано с очень убитым ноутом. Но все же я думаю, что когда буду вновь форматировать разделы, например после покупки десктопа — к черту эту btrfs, уж лучше поставлю старую надежную ext4.
Sign up to leave a comment.
Будущее файловых систем Linux