Для включения ядро Linux 6.2 предложены улучшения Btrfs, касающиеся исправления проблемы "write hole" в реализации RAID 5/6. Суть проблемы сводится к тому, что если крах случился во время записи, изначально невозможно понять какой блок на каком из устройств RAID записался корректно, а в каком запись не была завершена. В случае попытки восстановления RAID в подобной ситуации может произойти разрушение блоков, соответствующих недозаписанным блокам, поскольку состояние блоков RAID рассинхронизиорвано. Эта проблема возникает в любых массивах RAID1/5/6, где не принято специальных мер для борьбы с подобным эффектом...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58352
Скажите, а Btrfs уже готова для продакшена и для десктопа?
У меня часто сыпиться на внешних устройствах, которые я выдерагиваю после записи. Теперь я делаю sync до выдергивания флешки и вроде они перестали глючить. Для встроенных дисков - проблем небыло уже пол года, возможно они были связаны с btrfs-convert (там были фиксы). Вообщем я бы не назвал ее 100% надежной.
100 пудов юзается что-то архаичное. BTRFS уже давно считается стабильной фс. И если какие-то с ней проблемы, то время грешить на аппаратуру/дистр.
У меня глючила очень долго. Сейчас последние полгода-год нормально работает - никаких крешей. Но похоже все равно еще дыры есть. Например если записать 20 гигов на флешку и размнотировать - она размнотируется мгновенно. И если выдернуть - она может не просто потерять новые файлы, а сломаться полностью. Вообщем есть какие-то косяки.1) Кроме того btrfs не поддерживает badblocks. 2) Нужно запускать 'btrfs balance start -dusage=90 /' раз в неделю. 3) grub-32 не грузится со сжатой файловой системы. 4) нет поддержки zerofree, что очень плохо когда архивируешь или используешь виртуалку 5) нет хорошей поддержки fsck. у меня много раз было когда btrfs fsck проходит - а файловая система не грузиться или валиться. 6) плохая поддержка для deduping
Вообщем не 100%
> balanceПользоваться фс которая посыпется если не сделать во время балансинг это как сидеть на пороховой бочке. Возможно конечно она уже не сыпется от этого с тех пор как я последний раз её пробовал (и поскользнулся именно на этом), но учитывая что речь идет о самой штабильной фс (тм) я бы не стал на это надеяться
> Пользоваться фс которая посыпется если не сделать во время балансинг это как
> сидеть на пороховой бочке. Возможно конечно она уже не сыпется от
> этого с тех пор как я последний раз её пробовалЭто когда было? Сейчас оно глобальный резерв заводит и таких проблем не имеет. Фйэсбука это тоже видите ли кусало. Они и починили.
она не сыпиться - просто заканчивается место и ты не можешь удалить файлы. правда сейчас это исправлено - добавлен reserve в несколько гигов (зарезервированная память, которая использууется исключительно когда заканчивается место). сейчас она более менее. и много полезных и крутых штук.
Каким дистрибутивом ты пользуешся ?
У меня ВСЕ кроме boot на 3 машинах на btrfs. И флешки в том числе. Ща ежедневно еще и свет гаснет, никаких проблем. Вообще никаких. Ubuntu LTS 22.04.
До убунты пользовался gentoo сидел на LTS ядре. Все так же никаких проблем.
И нет я НЕ делал btrfs balance как устаномил систему (9 месяцев).
Невозможность именно что удалить файлы, если кончилось место -- это что-то новое. Такое вряд ли (сам не пользовался) было даже на ФС для пятидюймовых дискет Спектрума, где не было фрагментации и нужно было файлы специальной командой перемещать, чтобы высвободить свободное место.
> Невозможность именно что удалить файлы, если кончилось место -- это что-то новое.Чтобы атомарно провести операцию удаления файла требуется свободное место на диске. Иди учи матчасть.
> Такое вряд ли (сам не пользовался) было даже на ФС для
> пятидюймовых дискет Спектрума, где не было фрагментации и нужно было файлы
> специальной командой перемещать, чтобы высвободить свободное место.Всё правильно. Тупым файлухам это зачем?
2 года использую btrfs как корень с системой, работает. Ломается если я чтото эксперементирую.
тем временем на FreeBSD ZFS используется на корю с перманентными снапшотами.bectl create BeforeUpdateFromOfficialRepo
обновился, не понравилось
bectl activate BeforeUpdateFromOfficialRepo
перезагрузился и вот он тебе rollback. снапшот никуда не делся. хочешь, можно обратно на апдейты.
как тебе такое илон маск?
Тем временем, у людей zpool в коньках на домашнем пк все чаше встречается. Ага.
В линуксе даже фат 32 портится если не размонтировать.
А в sync режиме тормозит.
Нет какого-то среднего режима как в винде.
Как-раз таки средний режим есть: dirsync
Есть, просто надо ставить dirty_bytes/ratio поменьше
/etc/sysctl.conf# This fix enoumous big diry bytes (16 gb system vm.dirty_background_bytes 3.2 Gb ??? )
# 64 mb - when system starts writing to disk 64*1024*1024
# 256 mb - when system limits io to device speed 256*1024*1024
# Guys from SUSE recommends keep this in proportion 1:2 - 1:4
# Ubuntu guys recommends to set this even lower 16 and 42 Mb but well...
# This emulates near 1 gb ram default behaviour#let only 64 mb of pages in ram before writing to disk on background
vm.dirty_bytes = 67108864
#let only 256 mb of pages in ram before blocking i/o to write to disk
vm.dirty_background_bytes = 268435456## use this on low ram machile (32 and 64 mb)
#vm.dirty_bytes = 33554432
#vm.dirty_background_bytes = 67108864
На внешних устройствах лучше держать NTFS или exFAT, для совместимости с.
ИМХО, конечно же.
btrfs лучше всего для совместимости. для нее есть хорошие дрова для винды.
Т.е., выдергиваешь внешний носитель, не размонтировав ФС на нём, ну ССЗБ. Так-то любая ФС порушится.
после размонтированя конечно. посмотри как btrfs себя ведет если залить 20 гигов и размонтировать - она размонтируется мгновенно. похоже какие то журналы еще не записаны на уровне ядра.
Это зависит от параметра ядра.добавь это в /etc/sysctl.conf
#let only 64 mb of pages in ram before writing to disk on background
vm.dirty_bytes = 67108864
#let only 256 mb of pages in ram before blocking i/o to write to disk
vm.dirty_background_bytes = 268435456
С более-менее новыми ядрами это уже не надо: они сами замечают что накопитель медленный и урезают ему dirty по своей инициативе, чтобы размонтирование, отбор памяти у кэша и проч занимали бы человеческое время.А на быстром накопителе это только немного просадит производительность без особых положительных эффектов. Лучше ядра использовать не сильно древние, а на десктопе еще и low latency варианты к тому же. Для общей интерактивности системы.
> после размонтированя конечно. посмотри как btrfs себя ведет если залить 20 гигов
> и размонтировать - она размонтируется мгновенно. похоже какие то журналы еще
> не записаны на уровне ядра.Во первых у нее нет журналов в привычном понимании. Запись и является сама себе журналом, вся площадь фс - как большой журнал. За счет этого наглого чита избегают записи данных дважды.
К сожалению это не совсем бесплатный фокус, придает ФС специфичные свойства, приколы с сводобным местом частично проистекают отсюда, ведь к метаданным это тоже применяется. Но с аварийным резервом на подобные случаи с этим справились более-менее.
Во вторых, если dirty был, при размонтировании он прекрасно скидывается, что btrfs что осталдьных. Но начиная с некоторых ядер, размер бэклога сильно уменьшили для медленных устройств, от фс не зависит. Вообще-то это фикс того что тут как 12309 известно был и прилетел уже довольно давно... а если кто хотел махровый энтерпрайз с старым керенелом, так там как раз на сервере всем пофигу было на интерактивность, время размонтирования и прочие глупости, в древнее энтерпрайзное могли и не бэкпортнуть такое. И тут желающие энтерпрайзной крути сами себя обделили на нормальный юзер экспериенс, кто им виноват?
> У меня часто сыпиться на внешних устройствах,Эти с любой ФС сыпятся. Иногда даже настолько что совсем умирают. Там надо не только размонтировать но и EJECT делать, как безопасное извлечение в винде.
В этом случае оно еще более-менее остановит фоновые операции. Иначе - возможно все что угодно. Вплоть до слета транслятора - и горе вам если у вас бэкапов нет, это вообще не определяется как устройство, или определяется в сервисном режиме контроллера - но что вы с ним таким делать будете? Btrfs если dup включить, с его 3 копиями суперблоков даже зачастую выживает, гораздо чаще чем многие другие.
На этот нелепый вопрос давно ответила Fedora, openSUSE, SUSE и Oracle.
Спойлер : давно.
А красная шляпа что ответила?
Послали нафiг, сказав, что у нас есть свои велосипеды.
Ну вот теперь в своих Stratisах реализуют то, что уже давно готово в BTRFS.А на самом деле, они бы уже сейчас перешли.
Но, признаются, что тупо нет спроса у клиентов. На их сабреддите можешь почитать.
я бы хотел BTRFS в шапке, а еще чтобы они кеды вернули и LXQtно я не плачу за шапку, я пользуюсь клонами
Вряд ли будет. Как кеды, так и другое.
А если всё такое надо, лучше юзать Fedora.
В Альме уже сегодня есть кеды. В Евролинуксе тоже скоро обещали.
Fedora не годится для прода, а вот сервер с гуи часто встречается. И вместо LXQt приходится ставить кеды, в Роки есть. Но LXQt нет... и BTRFS тоже к сожалению.
Прод в РФ? Если да, то чем тебе Альт не прод? Платная поддержка, бумажная лицензия.
PS Не подумайте чего, мне Миша копеечку не платит :)
> Прод в РФ? Если да, то чем тебе Альт не прод? Платная
> поддержка, бумажная лицензия.прод в РФ и альт - это какой-то лютый мазохизм )))
>А красная шляпа что ответила?Тебе написали: Fedora.
федору на хлеб не намажешь.
шляпа ответила, что платных кастомеров btrfs не интересует.
Нет
Второй SSD на 2TB у меня на ней полгода крутится. Но там всего лишь файлопомойка да каталог стима. Другой SSD с корнем и хомяком пока страшно переводить )
держи нас в курсе, и бойся дальше
Понятно все с тобой: порнушку в хомяке держит.
Юзаю 7 лет, не потерял ни одного бита. Надо курить мануалы и следовать рекомендациям.
Zfs как-то умудряется работать без рекомендаций: поставил и поехал, ничего не сыпется. А с этим чудом нужно обращаться как с фарфоровой куклой
Умудряется работать ровно до обновления ядра. Потом нужно ждать от трех дней до недели, чтобы вначале в апстриме сделали возможной сборку модуля для нового ядра, затем в дистрибутиве ждать обновлений.
На LQO насчитали более 50 случаев, когда бэкпорт патчей из нового ядра ломал возможность сборки или функционирования модуля ZFS в старом ядре.
Именно поэтому ZFS нельзя для проды использовать
"Потом нужно ждать от трех дней до недели, чтобы вначале в апстриме сделали возможной сборку модуля для нового ядра" "Именно поэтому ZFS нельзя для проды использовать"Зато на прод можно ставить btrfs, который даже для загрузочного диска гипервизора не поставить в зеркало из 2х, т.к. он при деградации массива тупо отказывается работать пока не починят, вместо того, чтобы админ получил авто уведомление о проблеме и думал, когда и как ею заняться, а не бежал чинить, т.к. тюкают по голове звонками и чатами пользователи, оставшиеся без возможности работать :)
Так не надо делать из BTRFS зеркало RAID0.
Ну или не надо ставить GRUB в Legacy на этот же раздел.
> Так не надо делать из BTRFS зеркало RAID0.
> Ну или не надо ставить GRUB в Legacy на этот же раздел.Я написал зеркало, очевидно имея ввиду аналог RAID1, иначе написал бы stripe :) Да, именно на массиве типа зеркало btrfs так себя ведет (год-полтора назад как минимум таковым точно было его поведение согласно дизайну, сам в шоке и не поверил сначала своим глазам:)
Юзою ЗФС на продах ещё с 19-го года. Но в бубунте её модуль идёт сразу с ведром, потому проблем с модулем нет.
Поэтому в бубунте ядро в репы добавляют не в день релиза, а в день, когда все модули соберут. Иногда на это уходит неделя, если модульдел неделю думает, как модуль сделать для ядра.
> Юзою ЗФС на продах ещё с 19-го года. Но в бубунте её
> модуль идёт сразу с ведром, потому проблем с модулем нет.Кроме того момента когда вон там фикс на уязвимость выкатывают, а ты еще пару неделек уязвимый походи. С общеизвестной уязвимостью. Вот блин радость.
C ZFS было пару раз (в версии 0.6.x и 0.7.x), не монтировалась/не импортировалась штатно, приходилось импортировать принудительно для восстановления, вникать/искать в то какая там последняя рабочая транзакция, затем с неё сливать в новый пул на другом накопителе. Причём сбойный пул был на двух накопителях в mirror (сбоило на обоих накопителях). Но надо учитывать, что это был ПК без ECC с CPU и RAM в экспериментальном разгоне и сбой на FS возник после кучи ошибок и многократных зависаний системы. Однако если-бы был raidz, возможно восстановление было-бы ещё более заморочным, хотя я вряд-ли с raidz стал-бы сильно разгонять проц и память.
ZFS сыпется и теряет данные не реже, чем Btrfs. Вообще удивляет, как пипл верит ничем неподтвержденным мифам о супер-надежности ZFS. Где конкретные критерии стабильности и надежности ФС? Я лично более 1000 раз во время записи делал холодный ресет и Btrfs ни разу не рассыпалась.
> ZFS сыпется и теряет данные не реже, чем BtrfsВот это миф, т.к. ничем не доказать.
> Вообще удивляет, как пипл верит ничем неподтвержденным мифам о супер-надежности ZFS.
Пипл не верит, пипл разбирается в технических деталях и знает, что сама ZFS не крошится и данные если и потеряются, то лишь нескольких последних параллельных транзакций. И даже без ECC, и даже если выключить ZIL.
> Вот это миф, т.к. ничем не доказать.Поискари в интернете найдут вопли по любой ФС, а если вы хотите это конденсировано - придите в тусовку разработчиков, туда приходят те кому больше идти уже некуда.
> Пипл не верит, пипл разбирается в технических деталях и знает, что сама
> ZFS не крошится и данные если и потеряются, то лишь нескольких
> последних параллельных транзакций. И даже без ECC, и даже если выключить ZIL.Свежо предание.
Утверждение раз пять перечитайте, что-бы понять на что я возразил.> придите в тусовку разработчиков, туда приходят те кому больше идти уже некуда.
Давно там, по другим причинам. А вот вы сходите, и когда наскребёте статистику по потере данных в zfs и btrfs, тогда и приходите с доказательствами.
> Свежо предание
Ну можете обпроверяться.
Ресет убивает btrfs только в одном случае - с no barrier. Проблемы с данной фс намного глубже. Можно просто после перезагрузки получить сообщение о ошибках связанных с деревом. Лично я, встречался с этим дважды - разумеется, третьего не будет. Благо, с zfs данных никогда не терял.
Опыт штука такая, бтрфс в моем случае потерял два раздела, а зфс на тех же винтах после (которые я смог собрать в рейд уже без мдадма, вау) - ноль раз. Еще и балансить её не нужно и вообще прикасаться без необходимости, вот это чудеса. Конечно после такого опыта снова трогать бтрфс не хочется, и ничего подтверждать не надо
Ну, у меня регулярно(1-2 раза в год) с ней проблемы. Но может я его готовить не умею?!
Ёжики кололись, плакали, но продолжали жрать кактус
Непонятно зачем, когда zfs есть
Ежики, которые не в курсе, что ZFS нет в ядре, и никогда скорее всего, не будет, не знают, что бывает, когда модуль на собирается с новой версией ядра.
В бубунце модуль ЗФС идёт вместе с ведром. Чтобы этого добиться, там даже лояры прорабатывали этот вопрос. Полёт нормальный, с 19-20 годов пофиксили кучу багов и гонок c read-locks.
> В бубунце модуль ЗФС идёт вместе с ведром. Чтобы этого добиться, там
> даже лояры прорабатывали этот вопрос. Полёт нормальный, с 19-20 годов пофиксили
> кучу багов и гонок c read-locks.Выше уже писал. Попадание свежего ядра в реп из--за этого может на неделю зависнуть.
Несколько версий ядер с бэкпортироваными фичами просто в реп не попали, так как модуль с этими ядрами не собрался.
Ничего, подождёшь недельку, ухле ныть - оно даже если не обновится, ничего страшного, старое же ядро работает и собранный под него модуль работает же.
> Ничего, подождёшь недельку, ухле ныть - оно даже если не обновится, ничего
> страшного, старое же ядро работает и собранный под него модуль работает
> же.Недельку с незакрытой CVE жить?
А потом удивляются, почему нет сертифицированных PVE с ZFSoverFC...
Что ты как маленький? Пропатч текущее ядро сам.
> Что ты как маленький? Пропатч текущее ядро сам.Сколько анонимов с опеннета смогут обставить хотя-бы убунтовский кернел тим. Делаем ставки? :)
> Что ты как маленький? Пропатч текущее ядро сам.А что, от самопатча ядра модуль ZFS, который не собирается с патчем, сам соберется?
Пользую btrfs около 8 лет как основную и намерен продолжать использовать.Использую её на домашнем ПК/ноутбуке.
Поначалу были факапы примерно раз в год.
Последние пару лет использую нормальное оборудование и последние версии ядра - проблем не было ни одной.Пользовал btrfs на SMR-дисках при интенсивной записи: да, была СТАБИЛЬНО РЕГУЛЯРНАЯ беда раз в пол года примерно год назад (если игнорить тот факт, что SMR и интенсивная запись несовместимы).
У кого btrfs сыпется регулярно - ищите проблемы либо в аппаратной части, либо в своих навыках пользования имеющимися инструментами.btrfs - конфетка, золотая середина для локального использования.
> У кого btrfs сыпется регулярно - ищите проблемы либо в аппаратной части,
> либо в своих навыках пользования имеющимися инструментами.Вы просто не пробовали размещать btrfs на умирающих дисках, как это делают все недовольные этой ФС.
> У кого btrfs сыпется регулярно - ищите проблемы . . ., либо в своих навыках пользования имеющимися инструментами.Это как ? Компилировать ядро только по субботам ? А не в любой момент, когда захотелось ?
у меня есть большой массив, чексумы на данные - это киллер фича, уже нашел 2 битых файла за несколько лет эксплуатации (глюканул рейд контроллер), восстановил их из архивов
У меня на работе произошла забавная история.
Как-то я прочёл эту статью - https://habr.com/ru/post/559014/ - там про болячку btrfs с исчерпанием свободного места на диске.
Буквально через неделю коллега жалуется что у него убунта не грузится. Говорит что нет места на /. Я такой "а там у тебя случайно не btrfs??" - коллега "ага, оно самое".
Посмотрел, действительно, занято всего ничего - а свободного места ноль. Никакие команды не отрабатывают, в том числе и rm и fsck, ругаются что "недостаточно свободного места, действие не может быть завершено" - что-то в этом роде.
Мне было интересно можно ли оживить, но коллега просто форматнул / и переставил убунту, благо /home был отдельным разделом.
Эдик, ты зачем под чужим акком комментишь?
Tarpipe на другой диск, форматнуть и обратно?
Фиг знает.
Для десктопа сойдёт.
Для продакшна - зависит от нагрузки. Если много мелкой записи и критичны IOPS - лучше не трогать.
Готова, при наличии бэкапа. Но все равно медленнее zfs, которую можно гибко настроить. Чего не скажешь о btrfs.
Софтовый рейд в продакшене это колхоз.
А вот для десктопа - отличное универсальное решение.
А на самом деле:
- fix destructive RMW for raid5 data (raid6 still needs work)Т.е. великим трудом поправлен один частный случай да и то для raid5.
Дополнительно можно отметить рекомендации по использованию RAID5/6 от разработчиков, суть которых сводится к тому, что использовать btrfs не рекомендуется там, где данные имеют ненулевую ценность.
Поправил, не благодарите.
Да скорость внедрения фич уровня раст.
А чего это благо что хоум на отдельном разделе? Я не использую хоум вообще для хранения чего либо, там у меня только конфиги и всё которые скопированы дополнительно в другое место, поэтому хоум никогда не делаю отдельно, а для помойки использую том примонтированый в медиа
Знаю как красиво убить ZFS.
Надо во время записи на диск вызвать ошибку загрузки любого модуля ядра. Например, BT или WIFI.
Подобным zfs не убить.
"Также можно отметить, что для SSD в Btrfs в ядре 6.2 будет активировано по умолчанию асинхронное выполнение операции "discard" (пометка освобождённых блоков, которые уже можно не хранить физически). Достоинством этого режима является высокая производительность из-за эффективной группировки операций "discard" в очереди и далее обработки очереди фоновым обработчиком, из-за чего нормальные операции ФС не замедляются, как в случае с синхронным "discard" по мере освобождения блоков, а SSD может принимать более удачные решения."Целиком срисовано с F2FS, там именно так оно и работает.
Мне кажется я скорее ZFS в ядре дождусь, чем BTRFS станет продакшн реди
Я использую btrfs на системном ссд с данными, всё норм. Мне нужны сжатие текстовых данных и дедупликация, что в ext4 не удобно так это необходимость регулярно прогонять hardlink и отсутствие сжатия. Зачем тебе btrfs, mdadm не хватит?
хватит конечно! вы бы еще бекапы не компашки предложили
Используешь btrfs, а не удобна ext4?
И?
mdadm снапшоты не умеет.
mdadm сжатие не умеет.
Сжатие умеет tar. Снапшоты тоже. Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап. Рейд это не бэкап, ему не нужны снапшоты или сжатие.
> Сжатие умеет tar. Снапшоты тоже.Отлично конечно но в файловой системе недоступно и скорость доступа совсем другая.
> Сжатие умеет tar.Это когда tar стал уметь сжатие? То, что утилита tar может вызывать внешние утилиты для для сжатия, не означает, что tar умеет сжатие. Не зря многие виндовые ФМ архивов видят вначале архив gzip/bz2/xz/lz/zstd с одним файлом, а потом архив tar.
> Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап.
Да? А если данные в момент бэкапа активно изменяются, как будете бэкапить без остановки процесса, изменения данных?
> Рейд это не бэкап, ему не нужны снапшоты или сжатие.
Рейд, снапшоты и сжатие - это три вещи, как билет на поезд, сидение и скорость.
И на рейде можно держать раздел с сжатием, на котором можно использовать снапшоты.
Copy-on-Write позволяет избежать случайного повреждения нужных данных.
А сжатие позволит на одном разделе разместить
И как я могу архив tar смонтировать как раздел ФС?
GNU tar имеет встроенную поддержку для компрессоров и может напрямую их вызывать (даже zstd добавили, хоть и ограничено -- было например не перечислить дополнительные параметры в переменной, как с xz). Ни одна программа на свете не реализует эти алгоритмы сама, это не мешает им уметь в поддержку различных форматов сжатия. И да, твоё "один файл" не проблема, тарбол можно проиндексировать для получения произвольного доступа. Я использовал индексированные gz и есть даже для тарболов сжатых zstd. Что до "смонтировать", то ratarmount это видимо позволяет. Архиватора лучше и универсальнее tar ещё не придумали, зачем могу понадобиться снапшоты я до сих пор не понимаю. Некоторые безграмотные товарищи применяют их как альтернативу бэкапам, но это абсолютно некорректное использование.Зы
>если данные в момент бэкапа активно изменяютсяКонечно, остановить и сделать снапшот может быть на пару секунд быстрее, чем затарить, но что если что-то пойдёт не так из-за вмешательства в метаданные фс, сколько даунтайма это принесёт? Снапшот же изменяющихся данных будет равноценен хардресету и это очень не понравится софту, толку от таких снапшотов? И что будет, когда прошлые полноценные снапшоты без повреждений окажутся удалены и повреждённый окажется единственным в бэкапе? С тарболами всё шанс поиметь проблем ниже и если что-то не так, это можно обнаружить.
>Я использовал индексированные gz и есть даже для тарболов сжатых zstd.можно по подробно
>>Я использовал индексированные gz и есть даже для тарболов сжатых zstd.
> можно по подробноТакое пойдёт? Что-то вроде того и было https://github.com/devsnd/tarindexer/blob/master/tarindexer.py
Для zstd видимо придётся отказаться от стандартных утилит в пользу https://github.com/martinellimarco/t2sz/ из-за проблем с навигацией.
Упомянутый ratarmount всё это умеет.
> ratarmount это видимо позволяет1. fusermount. Корень не смонтировать.
2. RO, как и SquashFS.> зачем могу понадобиться снапшоты я до сих пор не понимаю
1. Загрузка ОС из снапшота, если в основной ветке ОС решила умереть из-за настроек.
2. Тестирование изменений в продакшине, дабы не тратить время на даунтайм при создании бэкапа и восстановлении из бэкапа. Регулярно используется в гипервизиорах от MS и VMWare только на уровне ВМ или их дисков.> Конечно, остановить и сделать снапшот может быть на пару секунд быстрее, чем затарить
Точно. 50 ГБ СУБД тарятся около часа. Снапшот делается 0,3 секунды. 3600 секунд всего на пару секунд быстрее, чем 1/3 секунды.
> но что если что-то пойдёт не так из-за вмешательства в метаданные фс.
Что может пойти не так, если средствами самой ФС в метаданные вносятся изменения?
Какой будет даунтайм, если на другой ФС из-за вмешательства в метаданные средствами ФС, она навернется?> Снапшот же изменяющихся данных будет равноценен хардресету и это очень не понравится софту
Какому софту это не нравится, если даже процедура бэкапов штатными средствами софта делает снапшот?
> И что будет, когда прошлые полноценные снапшоты без повреждений окажутся удалены
То же самое, что и при удалении неповрежденных бэкапов. Покажите, как восстановить инкрементный бэкап, если последний полный бэкап удален?
Всего-то полгода назад один крупнейший вендер бэкапов узнал, что создавал битые архивы из-за софтовых воин. Кто-то в системные либы внес правки, которые ломали бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.
> 1. fusermount. Корень не смонтировать.
> 2. RO, как и SquashFS.3. Времена операций сильно более другие. Одно дело вернуть систему в вид как было за 2 минуты после кривого апдейта, откатив как виртуалку. Совсем другое - с таром вон тем заниматься.
А еще - с таром можно промахнуться да не тот бэкап раскатать. И вот это бывает очень весело. В общем монтирование снапшотов и файловые операции с ними - сильно более другой уровень.
> бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.
Ну да. Меньше всего по пути. А какой-нибудь send еще может быть достаточно эффективным дифференциальным бэкапом, если понимать как это делать правильно.
>[оверквотинг удален]
>> 2. RO, как и SquashFS.
> 3. Времена операций сильно более другие. Одно дело вернуть систему в вид
> как было за 2 минуты после кривого апдейта, откатив как виртуалку.
> Совсем другое - с таром вон тем заниматься.
> А еще - с таром можно промахнуться да не тот бэкап раскатать.
> И вот это бывает очень весело. В общем монтирование снапшотов и
> файловые операции с ними - сильно более другой уровень.
>> бэкапы. А ФС работает не с либами, а чисто в пространстве ядра.
> Ну да. Меньше всего по пути. А какой-нибудь send еще может быть
> достаточно эффективным дифференциальным бэкапом, если понимать как это делать правильно.Точно.
> Сжатие умеет tar.Это все отлично конечно, но по времени операций и удобству рядом не стояло.
> Снапшоты тоже. Именно так бэкапятся изменения за неделю и в конце недели полноценный бэкап.
Сделать снапшот терабайтной ФС в сабже моментально. А таром так можно? То-то и оно :). Снапшот не бэкап но откатить систему после неудачного обновления или смены настроек удобно.
zfs модулем отлично работает
> BTRFS не продакш реди
> Oracle, SUSE, openSUSE : ну да, ну да, пошли мы нафiг
А чего не bcachefs? По слухам оно почти готово.
В бубунце модуль ЗФС поставляется в комплекте с ведром. Это вполне себе хороший компромисс.
discard не работает на многих ssd самсунга, зря активировали.
Проблема дешёвых ссд. в следующий раз не будешь вестись на рекламу и проплаченные отзывы и возьмёшь качественные adata (поспеши пока островной китай на плаву).
Адата и есть дешевый ссд.
Да, сарказм был силён. Но, при этом он собирается на нормальном контроллере и поддерживает discard.
> ...Но, при этом он собирается на нормальном контроллере...Ну как нормальным. У меня штук 7-8 ssd было, проблемный был один - Adata XPG. После поверхностного гугления ошибок из dmesg понял, что проблема с контроллером.
У них фишка в том, что они собираются на рандомном контроллере, в лучших китайских традициях.
> У них фишка в том, что они собираются на рандомном контроллере, в
> лучших китайских традициях.И еще и из рандомного флеша, который удалось как можно дешевле где-то ухватить. Мало ли, скидывал нормальный производитель брак, допустим, и выбор был между совсем под пресс, или вон тем дешевым, без претензий, с кучей бэдов это отдать? В первом случае еще за утилизацию платить надо, во втором - даже профит какой-то. Ничего личного, это бизнес.
Тут такое дело, продукция "нормальных" производителей у меня живёт стабильно меньше этой китайщины. А такими вещами с впариванием некондиции занимаются и вполне именитые фирмы.
> Тут такое дело, продукция "нормальных" производителей у меня живёт стабильно меньше этой
> китайщины. А такими вещами с впариванием некондиции занимаются и вполне именитые фирмы.Стабильно? :) А как это проверялось, если при каждой покупке оно из разных чипов понабрано и заранее не известно как это комбо вообще будет? Ну да, может сегодня и не брак сливали а склад разгружали от лежака, там как раз сейчас на радостях перепроизводство случилось после нехватки чипов, а тут еще китай от ковида встрял и чипы не исползует в ожидаемых объемах. Ну вот откуда б знать что впарят? На нормальные фирменные штуки гарантию дают, если случится фэйл - им же хуже, их попадение на деньги.
Работает, но не поддерживает корректно queued trim. Этим существенно замедляя операции во время собственно trim'а. fstrim даже лучше discard - после выполнения по расписанию trim'а, не вызывает падение производительности.
> Работает, но не поддерживает корректно queued trim. Этим существенно замедляя операции
> во время собственно trim'а.В вон том случае оно асинхронно относительно операций ФС случается и это уже не важно, ФС более не ждет завершение этих операций чтобы продолжить.
> fstrim даже лучше discard - после выполнения по расписанию trim'а, не вызывает
> падение производительности.Вон тот дискард в очереди - от этого не страдает. Там отдельная очередь, куда наливаются пожелания фс к очистке места. При возможности это группируется, а иногда оказывается так чт о туда вообще что-то новое записывают и смысла дискард делать уже нет, тогда он совсем отменяется. И единственное реальное отличие - больше не надо какие-то левые программы по таймеру запускать, прекрасно все в фоне само разбирается. Минус дурной системный сервис и побочная периодическая активность.
> discard не работает на многих ssd самсунга, зря активировали.Ядро само отключает для проблемных накопителей, там список вредин и плохих версий фирмварей ведется. Для таких ядро будет просто игнорить дискард, не повод из-за кривых железок обламывать всех остальных. Сделали так что пролетать будут только владельцы (некоторых) самсунгов.
Спасибо, но я лучше reiser5 подожду.
Его не будет. Ты как те психи, который ждали автобус на остановке где автобусы не останавливаются.
Я тебе не верю.
Поверь в Анонима как в самого себя. Главная заповедь опеннета.
Это рекурсивная вера.
> Скажите, а Btrfs уже готова для продакшена и для десктопа?openSUSE Leap 15.x:
Коневой раздел - Btrfs
Домашний раздел - Xfs
Суся это экспериментальный дистр. Никто суши даже платные на боевой сервер ставить не будет.
Рекомендую иногда выбираться в Европу, а не сидеть на диване где-то в Ростове.
Очень много стереотипов развеются.
> Очень много стереотипов развеются.Давно уже.
Не, или starздишь, или мало гуляешь.
Нужно больше.openSUSE и в госпиталях юзают (у них на сайте есть инфа, не падай ток в обморок).
И в учебных заведениях (можешь погуглить, только держи себя в руках).Давай, как погуляешь, дай знать.
Чтобы убедить что суши никто не использует? Ты бы сам сначала для начала выбрался из своего манямирка.
https://www.opennet.me/openforum/vsluhforumID3/129298.html#45
+ залети в метрику к ним и узри, сколько активных качалок с их серваков за ноябрь.
Упадёшь с дивана, уверяю.
Опять ссылку на свой манямирок дал? Ты мозгов вообще обучен пользоваться? Тебе явно к психиатору прими таблетки.
А Ростов, что, не в Европе?
> Рекомендую иногда выбираться в ЕвропуПффф... тоже мне, эталон.
Ну конечно, куда какой-то Европе до Г-нодонска или Задрыщинска из российской глубинки.
> Ну конечно, куда какой-то Европе до Г-нодонска или Задрыщинска из российской глубинки.Дооо, уязвил сарказмом, ага. Куда ж нам, сиволапым, до Шайзенштадта и Фартборо - это ж столицы мирового IT, на них равняются в Беркли, Тайбэе, Москве, Токио и вообще во всём мире.
> Никто суши даже платные на боевой сервер ставить не будет.В ИТ отделе лондонской бирже сидят д0л6oящеры, не слушали омнонимов с опеннета?
https://www.cnews.ru/news/line/londonskaya_birzha_zavershila...
Новости 33 миллиона лет ты так жестко рофлишь над самим собой? И то в те времена то что менеджеры получили больше откатов конкретно в этой фирме говорит ровно ни о чём.После этого никто, подчеркиваю никто из тех кто дружит с головой ни в какие серьёзные вещи суши не пихал.
> жестко рофлишьЙопт, малолетнее дебилушко. иди гугле HPE GreenLake, Kubernetes
И свои высеры про "откаты" и "никто" ссылками подтверждай. А то выглядишь де6илом
Йопт, старый маразматушка. Нет там никакого суши забудь. Суши есть у мелких отщипенцев типа тебя, с ограниченными умственными способностями. Твои нелепые попытки гуглить это просто смех. Ты смешном по жизни.
зачем такой изврат? сюся нормально полностью крутится на бтрфс
Там (в зюзе) уже сто лет дефолты такие, они были еще когда бтрфс сыпалась во много раз чаще чем сейчас, так что это нулевой аргумент
BTRFS это отладочная версия с халявным кодом, для тестирования алгоритмов ZFS.
Упрощаете товащи!
Здесь про рэйд5 новость. Использовать саму btrfs можно, кому нужно. А вот райд5 btrfs - кому нужно? Я бы послушал. Вот lvm к примеру срачей отмены ни у кого не вызывает, а хоть кто-то, ну то нибудь пользуется lvm raid5?
Ну я активно использую raid 5 в фс (zfs). Ибо оно имеет свои плюсы (как и минусы, разумеется).
Вообщем понятно, с такими детскими проблемами на btrfs в ближайшие 10 лет смотреть не стоит
10 лет назад было тоже самое. Подождем ещё 2 раза по 10 может взлетит
Ага, по этой логике и sqlite использовать не стоит, нигде и никогда. У неё как были проблемы с множественной записью так и остались.
> блок чётности можно воссоздать из данныхХммм... в самом деле... Зачем его вообще хранить, действительно?
Btrfs слишком глючно и ненадёжно. Лучше ext4 на сегодня нет, разве что zfs.
xfs. zfs - такой же комбайн, как и btrfs.
Однозначно zfs, если вам нужна btrfs. Минусов два - не в ядре и необходимость в тюнинге.
минусов гораздо больше. Начиная от отсутствия средств восстановления, продолжая невозможностью менять конфигурации сложившиеся исторически, и заканчивая все тем же смешным неумением без перезагрузки увеличить существующий раздел (только у л@п4тых, но беда в том что другой zfs для вас у меня уже нет)Про абсолютно неэффективную работу с памятью уже и не стоит...
Какой смысл использовать RAID5/6, когда диски стали большими и дешевыми? Время восстановления после сбойного диска будет куда больше чем у RAID1/10, а по стоимости выйгрыш минимальный.
Это справедливо лишь по отношению к потребительским накопителям (если говорить об ssd), модели серверного/промышленного класса нифига не стали дешевле.
Именно в том что они стали слишком большими (и слишком дешевыми).Время восстановления после сбоя любимого тобой raid10 тождественно равно нулю.
Потому что он не восстановится с непомерно высокой вероятностью.Выкрасить и выбросить можно сразу.
А 3way mirror все еще немного дороговат.
Это смотря сколько у тебя дисков.
Предлагаешь загнать 15 8Tб дисков с данными под тройную чётность, купив 45?
Не, я лучше куплю ещё два и обойдусь RAID6.
Тьфу блин под тройную чётность. Под тройную дупликацию, конечно же.
А ты - смелый!(/me немного подозрительно косится на свою конструкцию 9+2)
Ребята, не стоит использовать RAID 5/6. Никогда. Вы молодые, шутливые, вам все легко. Это не то. Это не RAID1 и даже не JBOD. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых – стоп. Остальных просто не найдут.
программировать, а не использовать. Использовать-то можно, если данные не нужны.Поправил, не благодари.
А в остальном все верно. Со времен Левенталя не осталось достаточно грамотных людей, способных в эту математику (и одновременно в код, но это неточно).
ВСЕ современные попытки почему-то (мы знаем почему) оборачиваются г-ном.
> в эту математикуВ xor то? Таблетки прими
угу, в xor. Вот в твоем лин00ps'е - с первого раза - нишмагли, в mdraid.
И его реализация raid6 просто превращала данные в мусор.Нет, не потому что перепутали байтики в xor. Она вообще не работала. А почему - в твоей, лапоть, церковноприходской школе, тебя не учат не то что понимать, а хотя бы осознать глубину своей безграмотности.
Лет пять назад ситуация повторилась в lizardfs. Там интереснее - там, видимо, именно перепутали, но за пять лет НИКТО не смог исправить. Ну не хватает им тебя, эксперта, чтоб показать, что там не так в ихнем xor.
А тех кто мог бы - Организация видимо убила и съела. Или как Левенталя... уж лучше б - съела.
В какой xor?
RAID6 - RS
Не, ну реализуется-то оно в основном и правда на xor и сдвигах, как любое умножение двоичных полиномов.
Только местному эксперту (к счастью для него) никогде не разобраться, почему иногда при этом получаются обратно данные, а иногда - фигня какая-то.А с теми кто могли - всякое странное происходило. Так что да, не советую в этом копаться. Просто не найдут. Или найдут разработчиком в оракле.
О да, лекцию по полям галуа давай заодно, если сам что-то смыслишь.
я как-то тестировал openzfs raidz1 (ихнее название для raid5) btrfs raid5. Создавал fs, писал данные, размонтировал. Потом один из 3 разделов перезаписывал /dev/urandomом. Монтировал обратно. После этого zfs ругалась, тормозила, но все данные возвращала (а resilver фиксил ситуацию к тому что было до). btrfs же вообще ничего не читала, ну может случайно 1 короткий файл из 10. Это цена отсутствия чексуммы на блок чётности.
Из аналогичного упражнения для mirror/raid1 обе фс выбирались без потерь.
mirror/raid1/raidz1/raid5
Всё - выкрасить и выбросить.Либо 3-way mirror, либо raid6.
при отсутствии контроля четности второе ничем не лучше. Ну есть у тебя теперь второй блок контрольных данных. А какой поврежден - по прежнему неизвестно. Может этот самый второй. Может первый. А может сами данные. raid делали для защиты от отказов носителя, не от silent corruption или отказа управления.
Чисто формально, в случае порчи *одного* любого блока из страйпа raid6 данные можно восстановить. Но это существенно большие вычисления чем в случае, если известно, какие блоки пропали. И mdraid так не умеет.
> Но это существенно большие вычисленияНе только, это ещё и больше i/o, поэтому сомневаюсь, что оно где-то используется при штатной работе для контроля целостности данных
> Чисто формально, в случае порчи *одного* любого блока из страйпа raid6 данные можно
> восстановить.э... как? Если мы не знаем, какой именно это блок? Если у страйпа хотя бы был бы общий контрольный, не ec, код - то да, можно собирать его всеми способами выкидывая все блоки поочереди, пока контролька не совпадет. Ну или ты предлагаешь мажоритарным методом - каких больше, тот и прав? Так и xor можно. Правда, необязательно это будет правильный ответ ;-)
> mdraid так не умеет.
мне кажется, так никто из EC-based не умеет.
Ну и да, в случае зеркал с >2 копиями тоже такто можно задетектить порченный блок и восстановить. И опять mdraid не умеет.
Ну то же самое - либо контрольный код, и просто прочитать тот где совпало, либо те где больше одинаковых, те и правы.
Но опять же сомневаюсь что хоть что-то так работает.В synology mdraid вроде умеет в какой-то self-healing, "но это неточно" и исходников нет.
Btrfs прекрасно чинит себя с второй копии, csum error, corrected и дальше поехал. Даже на однодисковых нечто с DUP прокатывает, хоть это и слкгка изврат, конечно.А с вон той механикой были проблемы если частичная запись потерялась и точно не известно какие блоки насколько записались при отвале RAID. Делать "журнал записи/RMW в RAID56" в btrfs принципиально не хотели из-за характерных проблем перфоманса. А тут вот некий компромисс нащупали, оверхеда добавить может, но не столько, в паре с хранением метаданных RAID1/RAID1C3 это уже начинает смотреться достаточно осмысленно и уже не имеет таких откровенных проблем для осыпания.
На самом деле если понимать суть проблемы, с RAID56 в сабже можно было жить давно. Просто после такого краха для предотвращения вон тех блоков надо scrub было делать. Чтобы их найти и нейтрализовать ДО того как что-то развалилось. Но это достаточно ресурсоемко большой хранилке, хоть и фоновое и вообще не вредно периодически для понимания не сыпется ли что-то уже понемногу в железе.