Сформированы корректирующие выпуски проекта OpenZFS 2.1.14 и 2.2.2, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. В обновлениях устранена проблема в коде проверки согласованности кэша dnode, приводящая к повреждению данных в файлах, содержавших пустые области, при их копировании после внесения изменений...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60212
Живём!
Чётенько описали подробности проблемы. Спасибо!
Объясните мне - зачем cp лезет в структуру файловой структуры нарушая уровни абстракции? Ну понятно что для убогих ufs, ext и т.п. это необходимо - но ZFS абсолютно другой класс ФС.
UFS норм FS. Третий день использую,никаких косяков нет.
mksnap_ffs /home/.snap/delmeкак, все еще - нет косяков?
не знаю, мне больше по душе Flatpak
> UFS норм FS. Третий день использую,никаких косяков нет.Ну тогда bcachefs просто эталон стабильности. Уже неделю работает и никаких особых траблов вроде. Только еще умеет сильно поболее этого unknown flying sh...
/dev/null - недостижимый идеал
> /dev/null - недостижимый идеалНу, блин, с него виртуалка не хочет грузиться что-то. И с /dev/urandom кстати тоже.
не правильно понимаете сабж
> Проблема проявляется при использовании утилит копирования файлов, умеющих определять и оптимизировать пустые области в файлах.умеющих ПРАВИЛЬНО определять
в общем и целом новость такая - zfs НЕ использует внутренние структуры ядра (vfs/итд), а тянет свои ( ещё солярную spl/итд)
Но иногда очень хочется использовать удобные новые возможности ядра:
> … OpenZFS, начиная с выпуска 0.6.2, поддерживает операции SEEK_HOLE и SEEK_DATA …но не всегда получается кусочно-разрывная интеграция ежа с ужом.
как-то так.
в общем интересующимся - `man 2 lseek`
> Since Linux 3.1, Linux supports the following additional values for whence:
> SEEK_DATA
> …
> SEEK_HOLE
> …
Ну ты бы прежде чем писать заумную ерунду посмотрел бы что написано в тексте новости, а из него догадался бы сходить в man lseek чтобы понять куда конкретно лезет cp. По крайней мере ддя ценителей уровней абстракции эта операция должна быть посильной.
> Объясните мне - зачем cp лезет в структуру файловой структуры нарушая уровни абстракции?
> Ну понятно что для убогих ufs, ext и т.п. это необходимо - но ZFS абсолютно другой класс ФС.А она - не лезет. И лишь взаимодействует через апи файловых операций. Со временем и вот такие, для оптимизация операций появились. А ZFS и лоханулся в их реализации. Заметив сильно опосля, когда это coreutils в массы принесли. Так все просто и банально.
Но вы там не расслябляйтесь, кроме coreutils есть и другие программы - вот теперь и гадайте у кого из вас данные побитые. Хотя там детектор есть, но его методы работы...
Нда, оголтелые в своем репертуаре. Кто нибудь из вас хоть исходники cp из coreutils видел?... Хотя о чем я спрашивают - понятно что нет. Бред то нести это не изучать вопрос перед ответом.
> Нда, оголтелые в своем репертуаре. Кто нибудь из вас хоть исходники cp
> из coreutils видел?... Хотя о чем я спрашивают - понятно что
> нет. Бред то нести это не изучать вопрос перед ответом.1) Да, я видел эти исходники. Покажи мне там "нарушение уровня абстракций", чудак. Если это про экстенты, программы всегда писали данные в файлы как (offset, len) и операция над "экстентом" мало чем отличаются, экстент это тоже (offset, len). Да, там предполагается продвинутая ФС которая понимает ряд расширенных запросов. Но как это внутри ФС сделано - программы не знают. Это абстрактный запрос в терминах операций над регионами. В ряде случаев ФС даже имеет право переиначить и выполнить "неточно", как умеет. Как минимум для "same extent" ioctl.
2) Судя по рейтингу твоего "умного" вопроса оголтелый был не я...
3) Расскажи как делать допустим офлайн дедуп или - вот - копирование-как-рефлинк по твоему суперценному мнению?
4) Если тебе интересно, я даже и ответку этих интерфейсов из 1) видел в btrfs и bcachefs.И нет, "онлайн дедуп" жрущий 100500 рам и проца - вообще совсем не эквивалент этих операций. Которые могут быть достаточно просты, дешевы (рефлинк вообще почти моментальная штука, только в метаданных пометить что те же блоки юзаются еще кем-то) или по крайней мере дефернуты по времени ("same extent" ioctl).
Просто для понимания - btrfs делает рефлинк на 3-терабайтный образ винча создавая "типа копию" которая ведет себя как независимый файл за примерно секунду. А ты можешь, конечно, честно скопировать все 3 терабайта (не забудь засечь сколько займет) а потом по сути отменить это действо дедупом (тоже не забудь зесечь сколько это заняло). А при этом потребуется еще и +3 терабайта свободного места на такой "transient". А вон там оно с самого начала - "идеальный дедуп" и места не занимает, только то что изменится и закопировано в сторону CoW. И не уметь подобные интерфейсы для CoW системы вообще-то довольно глупо. В лине этому даже XFS каким-то чудом научился. Я не знаю как они сову на такой глобус натянули, но ZFSники сделали это сильно позже и когда non-cow дизайн получает cow фичу раньше чем cow-дизайн это полкило прикола! Bcachefs тоже это умеет с самого начала.
Итого, на данный момент в клуб новых интерфейсов вступило минимум 4 файлухи: bcachefs, btrfs, xfs, zfs. И я нахожу умение в такие фичи логичным для next-gen CoW дизайнов, классическая семантика IO операций вообще - не про них, у них by design есть фичи которые классическими апями posix не описываются.
p.s. а самое прикольное во всей этой истории что баг вообще к рефлинкам походу не относился, они "виноваты" только тем что позволили каким-то гентушникам активнее юзать вон тот кусок механики ФС, и там наконец что-то отвалилось под нагрузкой в каком-то древнем баге как воспроизводимая операция. При том отваливаться оно могло и без этого, просто ситуацию создать не очень просто - условия специфичные. По этой причине кого-то явно ждут "приятные" сюрпризы с корапченой файлухой, которую они не заметили.
Странно, что до сих пор нет исправления ошибки, приводящей к появлению файлов.
>return (B_TRUE);Над сишниками смеются, что они переизобретают строки. Но ситуация ещё хуже: они даже bool переизобретают. Скобочки ещё какие-то поставили при возвращении. Это бездна.
Если это троллинг то только для тех кто не знает Си хотя бы на начальном уровне.
Если нет - учите язык перед тем как писать подобное.
СИ настолько качественно продуманный язык, что stdbool.h в стандартной библиотеке появился в версии стандарта C99.
Т.е через 10 лет после выпуска первого стандарта C89. (Ну... а фигли торопиться))
И примерно через 21 год после выпуска "не-стандарта" K&R.
У него по крайней мере есть стандарт :)
С это и есть программирование в чистом виде - все эти параметры на стеке, условные переходы, всё это и есть разработка без уровня абстракций. То, что тебе понадобилось побитово делать маркеры успеха в виде булевских переменных, да и еще под это почему-то затребован отдельный тип данных - это уже абстракция, пандус у входа.
Забыли про флаги, от которых абстрагировались в Си.
Че там по расту? Уже придумали и описали единственную имплементацию и реализацию вектора? Нет? Т.е. очередная обнова сине-розовых ленточных должна сломать поддержку в RO прошивке нескольких лямов готовых модемов у увожаемых партнеров в костюмах от гуччи?
Покормил.
> Скобочки ещё какие-то поставили при возвращении. Это бездна.Уберите скобочки - можно новую версию анонсировать. Правда, ничего в логике не поменялось, что кто-то при деле.
Скобки могли оставить для соблюдения единообразия кода. У Си и так простой и чистый синтаксис, а соблюдение единого стиля кода делает его вообще идеальным.
> Скобки могли оставить для соблюдения единообразия кода. У Си и так простой
> и чистый синтаксис, а соблюдение единого стиля кода делает его вообще
> идеальным.
#define MAP_LIST(f, ...) EVAL(MAP_LIST1(f, __VA_ARGS__, ()()(), ()()(), ()()(), 0))
...
volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
Это лишь доказывает, что и тридцать ключевых слов -- дело тяжелое, ты вот даже не осилил нечто корректное написать, но мнение имеешь. Тьфу.
> Это лишь доказывает, что и тридцать ключевых слов -- дело тяжелое, ты
> вот даже не осилил нечто корректное написать, но мнение имеешь. Тьфу.Очередной кек-сперд опеннета опять пишет о себе в третьем лице?
https://github.com/swansontec/map-macro/blob/master/map.h
/**
* Applies the function macro `f` to each of the remaining parameters.
*/
#define MAP(f, ...) EVAL(MAP1(f, __VA_ARGS__, ()()(), ()()(), ()()(), 0))
cat hello2.c && gcc -Wall -Wextra hello2.c && ./a.out
#include <stdio.h>
int main( void )
{
volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
printf("Hello borsch %p", borsch);
return 0;
}
hello2.c: In function 'main':
hello2.c:4:5: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
4 | volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
| ^~~~~~~~
Hello borsch 0x0%
так а где корректность-то? в чем смысл того, что ты тут выдал?
"а вот так вот можно написать и скомпилеца, ыхых, сишка, диды, дырени" -- это твое показательное выступление?Озвучь в паре предложений, что ты хотел проиллюстрировать.
> У Си и так простой и чистый синтаксис,...
> так а где корректность-то? в чем смысл того, что ты тут выдал?Причем тут "корректность"-то? В чем смысл того, что ты тут выдал, спрыгнув с темы (ну или как обычно - вообще не читав обсуждение, просто нафантазировав себе что-то)?
> "а вот так вот можно написать и скомпилеца, ыхых, сишка, диды, дырени" -- это твое показательное выступление?
А это твой показательный слив, с унылыми передергами и откровенными приписками из собственных фантазий? Уныленько, че.
ну, насколько вижу, ты привел примеры какой-то фигни в ответ на "скобки могли оставить для соблюдения единообразия кода. У Си и так простой и чистый синтаксис, а соблюдение единого стиля кода делает его вообще идеальным."только ты решил, что взять хитрожопые трюки с ПРЕПРОЦЕССОРОМ (ого, препроцессор, который просто s/x/y/, на этом его работа всё, и который не си); что взять нагромождение слов, которые сканпеляюца, но не несут никакой смысловой нагрузки -- это разбить в пух и прах аргумент выше? Ну так ты выдал шизофазию, которая и не опровергает ничего, и не доказывает. Ну, кроме того, что "и так можно".
Что ты сказать-то хотел?
> ну, насколько вижу, ты привел примеры какой-то фигни в ответ на "скобки
> могли оставить для соблюдения единообразия кода. У Си и так простой
> и чистый синтаксис, а соблюдение единого стиля кода делает его вообще
> идеальным."Теперь поподробнее, какие буквы в "Си и так простой и чистый синтаксис" тебе не понятны и с каких пор используемый реально (вот этот вот MAPLIST в разных вариациях встречается только так) стал "фигней"?
> только ты решил, что взять хитрожопые трюки с ПРЕПРОЦЕССОРОМ (ого, препроцессор, который
> просто s/x/y/, на этом его работа всё, и который не си);Прероцессор "не си"? Надеюсь, это такая унылая демагогия, иначе на этом можно и закончить обсуждение с очередным кекс-пертом.
>> "У Си и так простой и чистый синтаксис"
> что взять нагромождение слов, которые сканпеляюца, но не несут никакой смысловой
> нагрузки -- это разбить в пух и прах аргумент выше? Ну
> так ты выдал шизофазию, которая и не опровергает ничего, и не
> доказывает. Ну, кроме того, что "и так можно".
> Что ты сказать-то хотел?Поясни, это из раздела "Папа, где море?" или "нищитаица!"
Ну и да, "шизофазия" это для только для кекспертов опеннета, так-то применение единичного, константно-волатильного указателя на какой нидь int - вполне встречается для общения с железками (пусть там обычно и не signed long int) ...
Хочешь пиши 0 и 1 вместо fal$e/TrUe. А потом мы посмеемся над твоими макросами.
Разве BTRFS не является переработанной и улучшенной версией ZFS?
нет
бтр это недозфс.
> Разве BTRFS не является переработанной и улучшенной версией ZFS?Является. Но файнбои зфс не унимаются.
А ENOSPC при диске заполненном от силы наполовину с необходимостью ребалансировки постоянной это у бтр такая фича улучшенная по сравнению с зфс. И рейд5/6 недоделанный тоже.
> А ENOSPC при диске заполненном от силы наполовину с необходимостью ребалансировки постояннойБрехня. Как раз наоборот можно поймать исчерпание свободного пространства при балансировке или дефрагментации. Я два раза на такое попадал у себя. А если не лезть с ручным обслуживанием, то проблем не возникает.
> рейд5/6 недоделанный тоже.
Да. Но лично у меня только 0 и 1. Так что пофиг.
Не шутите так. Даже близко нет!
>Разве BTRFS не является переработанной и улучшенной версией ZFS?улучшенной нет. в бтре нет шифроавния и рэйды 5-6 итд кривые. но если ничего из этого тебе не нужно, то бтрфс конечно тортее. особенно на oracle linux (у дебианов-бубунтофф понятное дело экспертизы нет)
>>Разве BTRFS не является переработанной и улучшенной версией ZFS?
> улучшенной нет. в бтре нет шифроавния и рэйды 5-6 итд кривые. но
> если ничего из этого тебе не нужно, то бтрфс конечно тортее.У него менеджмент гораздо круче. Ну так, мелочи какие. Можно перегриать почти все. На ходу. И это даже относительно безопасно в силу природы CoW. И непозорно работает даже без подпора гигазами рамы, в отличие от ZFSа - который сам по себе редкостный тормоз без ломовых кешей в оперативе.
И вообще - btrfs намного универсальнее и не такой энтерпрайзный пережорок как ZFS. Может DUP на ноутбучном диске например, переживая бэды, и при этом снапшотя систему и не выжирая гигазы на кеши. А с ZFS что в таких конфигах ловить?
> Разве BTRFS не является переработанной и улучшенной версией ZFS?Это вообще совсем разные кодовые базы - и структуры ФС имеют мало общего. Единственное что хоть как-то пересекается это общая идея CoW.
https://www.enterprisedb.com/blog/postgres-vs-file-systems-p...btrfs полный хлам в PostgreSQL применении...
Сижу на BTRFS с 2012 года и не потерял ни единого бита информации. А на ZFS постоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что ZFS - надежная ФС? :)
Расскажи это Шишкину.
Какому Шишкину? Не тому ли, который грозился выпустить Reiser5, но так и забросил ее, не осилив ее разработку? Мнение теоретиков и прочих Шишкиных меня не интерсует.
Да просто Шишкин понял что с такими токсичными людьми как Линукс Торвальдс нельзя иметь никаких дел. Всё равно не оценят, что бы ты ни сделал. Не писать же ещё и своё ядро в дополнение к ФС...
Чего? Шишкин - сам токсичен, дозиметр аж зашкаливает при его появлении. Кстати, когда он Reiser5 релизнет, а то перестал коммитить аж 2020 году.
Шишкин в отличие от некоторых не имеет привычки показывать средние пальцы и оскорблять всех без разбору. А у вашего божка все плохие, один он белый и пушистый. Нашкрябал кое как своё кривое ядро и ходит тридцать лет короной звенит...
Судишь по обложке.
Ты от темы не уходи. Шишкин обещал выпустить Reiser5, поливая фекалиями остальные ФС. В итоге слился как позорник, забросив разработку Reiser5 в 2020 году. Сдулся твой Шишкин.
Он не сдулся, у него саббатикал. Понимаешь, устал он очень. Сперва писал код, потом давал интервью, потом думал много. Потом времени не было. Ну и утомился в конце концов. Но ты погоди немного, вот отдохнёт и всем покажет! Если время будет, конечно. Сам знаешь как оно бывает со всеми этими интервью, славой, известностью.
Возможно Шишкину просто надоело заниматься альтруизмом и он предпочёл посвятить себя чему-то более полезному.
> Возможно Шишкину просто надоело заниматься альтруизмом и он предпочёл посвятить себя чему-то
> более полезному.Поэтому будущее и будет принадлежать упрямому Кенту. А этот господин займется очередной НЕХ.
> Шишкин в отличие от некоторых не имеет привычки показывать средние пальцы и
> оскорблять всех без разбору. А у вашего божка все плохие, один
> он белый и пушистый. Нашкрябал кое как своё кривое ядро и
> ходит тридцать лет короной звенит...В отличие от шишкина он то на гора результат выдает, каждые несколько месяцев, оправдывая ожидания всех кто ему и делегировал звон короной, совершенно добровольно. За это его звон короной можно и потерпеть - в отличие от всякого пустозвонства БЕЗ релизов чего-то полезного и юзабельного как итог. В конечном итоге засчитывается результат.
И у шишкина результаты его жизнедеятельности - они в чем проявляются? И почему это круто, хорошо и правильно? Впрочем если вдруг - вы в вашем праве использовать его ФС, разумеется. Кто же вам это запретит?
А в чём проблема, ZFS вроде как тоже нет в ядре, что ему мешает дорабатывать ReiserFS без включения в ядро?
>А в чём проблемабасня Крылова - Л,ЩиРак :)
пс: "а возу все нет ходу!"
А кто там в разные стороны тянет? Там только Шишкин с помошниками.
> А кто там в разные стороны тянет? Там только Шишкин с помошниками.мораль сего комента такова, что согласованность в разработке должна быть, выше кто-то там жаловался, почему "поделие" (опензфс) нарушает уровни абстракции и т.д., а все почему? -> "вроде как тоже нет в ядре"!
пс: ток не будем раздувать холивар про "кто, под чью дудку плясать должен" - мораль -> "когда в товарищах согласья нет"
Шишкин, как раз, сомневается в её надёжности.
> Расскажи это Шишкину.Ну так пользуйтесь ФС от Шишкина, если это для вас лучше работает. Но reiser3 из майнлайна кажется скоро вылетит как заброшенный код, reiser4 там никогда и не было, а reiser5 это вообще vaporware какое-то где господа лучше всех знают как надо, но - толком не могут определиться как же это - так что оно вообще что-то этакое, существующее в основном на бумаге.
Когда выйдет reiser5, тогда и буду смотреть что это такое, а пока меня и ZFS устраивает. Лучше ещё ничего не придумали.
> Когда выйдет reiser5, тогда и буду смотреть что это такое, а пока
> меня и ZFS устраивает. Лучше ещё ничего не придумали.Не хочу показаться скептиком, но по моему Шишкин лучше всего умеет рассказывать как (не)надо. А вот создавать себе команды или релизить файлухи в юзабельном виде - кажется, не его.
Так что вот, доморощенный Кент сделал академика как с куста. Как и предсказывалось сколько там времени назад. Приятно быть провидцем...
Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что BTRFS - ФС?
У btrfs нет багов. Баги -- это когда ФС в целом надёжна, но иногда в коде обнаруживаются ошибки. А btrfs это одна сплошная ошибка, которая разваливается от любого неосторожного движения как трухлявое дерево.
Трухлявое дерево - это твое протухшее глючное железо. Железо замени на надежное. Ну и руки свои выпрями.
А вот ZFS прекрасно работает на любом железе, для неё не надо создавать тепличные условия. В этом кстати главная проблема btrfs -- в том что она хорошо работает только на бумаге и в стерильных лабораторных условиях.
Наглое вранье. Ни одна ФС не спасет от повреждения данных, которое происходит из-за глючного железа. У тебя проблемы с причинно-следственными связями.
Бтрфс кстати спасает, но, до тех пор, пока всё складывается удачно. Это могут быть и годы, и неделя. Зависит от характера повреждений опять же. Но главное, она просигнализирует о проблемах задолго до того, как ситуация пример необратимый характер.
Главное не забыть докупить дисков чтобы можно было освободить место в пуле ))
нееее, это так не работает. Их надо подключить ДО того как понадобилось место в пуле. Иначе не хватит места для добавления места. Оно ТАК работаит.(подозреваю что костылик с zpool attach тоже может слегка побаливать этой же болячкой, но он таки во-первых костылик и ему можно, во-вторых к этому моменту все будет уже давно плохо и в общем-то кто не почесался вовремя - сам виноват)
> нееее, это так не работает. Их надо подключить ДО того как понадобилось
> место в пуле. Иначе не хватит места для добавления места. Оно
> ТАК работаит.Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень хорошо :)
> (подозреваю что костылик с zpool attach тоже может слегка побаливать этой же
> болячкой, но он таки во-первых костылик и ему можно, во-вторых к
> этому моменту все будет уже давно плохо и в общем-то кто
> не почесался вовремя - сам виноват)Ну а btrfs'ники свои проблемы решили, как обычно. И кент конечно тоже стырил решение. Довольно предсказуемо, я б сказал.
> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем
> никак - возьмет из него. Кент, кстати, этот урок усвоил ооооченьа если уже взяло? Потом еще разок взяло... а потом почему-то в доме у кролика вообще ничего не осталось.
И вот шансов на то что застрявший медведь схуднет через пару недель - не очень.
>> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем
>> никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень
> а если уже взяло? Потом еще разок взяло... а потом почему-то в
> доме у кролика вообще ничего не осталось.Если оно это на актуальных версиях ядер делает - навесить баг, имхо. Но у них там так то для тестов целый книгоморд был - и они как раз подобные приколы гасили энное время назад. В обычной ситуации на ЭТО с современными ядрами вообще нарваться малореально - надо нечто супернагруженное, как у мордокниги, тогда под ломовой нагрузкой, на нескольких тазиках из всего парка, за недели-месяцы, может и получится. Но после тех фиксов уже вроде и там не получается, при том что нагрузки фэйсбука -
> И вот шансов на то что застрявший медведь схуднет через пару недель - не очень.
В обычной жизни увидеть это - ну даже не знаю. Если у тебя свой книгомордий есть - можно попробовать, конечно. Ну или кернелы древние.
А так как видишь, свои приколы есть у всех. Кент глядя на это завел какой-то радикально более толстый резерв сразу, чтоб на уже известные грабли не вставать. Удобно же когда граблю nextgen дизайна до тебя любезно оттоптали, можно - вот - немного переиграть :). Круто конечно все заранее знать и заранее предусматривать - но так не бывает.
Как и превосходное железо на глючной FS.
Вообще-то только btrfs обкатана всеми и везде где только можно и зфс никто не использует в адеквате (потому что не предоставляет сколько-нибудь значимых преимуществ и потом приходится ныть на форумах).
расскажи это пользователям TrueNAS, TrueNAS или OMV
*FreeNAS
Лохи они и в Африке лохи, на то они и лохи.
Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем, Red Hat (Все из Федоры идет в RHEL после обкатки).
rhelovskiy сектант все с тобой понятно) жуй свой интырпрайз и не мешай крутить другим педали своих велосипедов
> Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs
> в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем,
> Red Hat (Все из Федоры идет в RHEL после обкатки).Что, редхат таки устал пыжиться прикрутить эрзац-подобие scrub к XFS? Там где-то в процессе аж майнтайнер слинял. Вооооон там, с btrfs'никами отвисает теперь. Популярное направление стало - почему-то из редхата все блочники-файлушники куда-то в сторону btrfs драпают. Тенденция, однако!
> Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs
> в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем,
> Red Hat (Все из Федоры идет в RHEL после обкатки).Facebook строит отказоустойчивую систему, так что пример не очень удачный, для них потеря данных на отдельном сервере/стойке или даже ДЦ не критична.
Synology — совсем уж entry-level, так что тоже не очень удачный пример.
RH активно продвигал xfs, не слышал, чтобы они отказались.
Остаётся разве что Fedora, понаблюдаем.
Но у меня пока ощущение, что скорее bcachefs допилят до готовности к проду в многодисковых конфигах, чем btrfs.
> RH активно продвигал xfs, не слышал, чтобы они отказались.0) Из RH удрапало дофига блочников и файлушников. Воооон там вокруг btrfs теперь тусят, лол.
1) Btrfs в федору втянули.
2) XFS - такая сова на глобус что там аж майнтайнер удрапал в панике не так давно. Его роботы багами засыпали в хламину, он и промямлил - мол XFSv4 код дидов такой крап что когданить потом пофиксим его, путем дропа, останется только v5. Но впрочем даже это будут пытаться другие.
2.1) И да, они там героически упираются хотя-бы аналог scrub запилить. При том уже несколько лет. Видимо идея делать вот именно fsck, именно при загрузке, вообще легаси пованивает с одной стороны, а проверять состояние данных в рантайм с другой стороны - как-то более актуально, ибо какие-нибудь серваки и что там еще могут ребутать не очень то и часто, да и время этой операции по всей площади - изрядное. Одно дело фоновое чтение с idle приоритетом, другое - что-то там чекать при загрузке и проч.
3) Пойнт вон той камасутры для меня загадка. Сколько это УГ не гальванизируй, btrfs/bcachefs по управлению из ЭТОГО не получится. А все эти сратисы с пыхтонрасом и этажеркой LVM/MD/DM/... - могу себе представить как это будет работать. Особенно если в процессе менеджмент операции питание слетит или там что еще.Говоря за себя - меня тот блевотный менеджмент который редхат пытался сватать - вообще совсем не устроит после того как я Btrfs попробовал. Вот эти сделали управление файлухой и пространством так как это и должно было быть на самом деле.
> Остаётся разве что Fedora, понаблюдаем.
> Но у меня пока ощущение, что скорее bcachefs допилят до готовности к
> проду в многодисковых конфигах, чем btrfs.Ну вот в данный момент времени я btrfs использую в вполне "продакшновых" сценариях, а bcachefs - ну я там уже пару багов отхватил. Но его только комитнули и это нормально.
И да, если кто думает что Кент все идеально предусмотрел... вон там уже блаблабла на тему того что надо б инверсные индексы на манер btrfs'ных backrefs, а то скорость операций менеджмента что-то дескать "не очень". При том этого еще нету на уровне структур и проч даже. У него еще есть прикольная штука - erasure coding. Но и это WIP жесточайший.
Btrfs-ники так то тоже свое дело делают. Недавно запилили bg_tree с которым btrfs маунтится аж быстрее ext4 (и bcachefs). На механике, VM или медленных флехах бывает довольно заметно. И какие-то расширения RAID56 пилят в фоне, дабы write hole более радикально заделать. Но у них core дизайна куда стабильнее если RAID56 не надо, имхо. Это уже продакшновый дизайн, видавший ломовые нагрузки уровня FB и проч. И основные самые жирные баги в нем - уже отловлены. В отличие от вон того - там поток багов такой что Kent почти каждый -rc прилично фиксов насыпает. Но это нормально в данный момент времени.
Оно же было в RHEL 6/7 как Tech preview, а потом эту каку выкинули..The Btrfs file system has been removed in Red Hat Enterprise Linux 8.
You can no longer create, mount, or install on Btrfs file systems in Red Hat Enterprise Linux 8. The Anaconda installer and the Kickstart commands no longer support Btrfs.
> Оно же было в RHEL 6/7 как Tech preview, а потом эту каку выкинули..Я б сказал что скорее блочники и файлушники - выкинулись из редхата, ну они и не смогли майнтайнить компонент. Не знаю что там случилось но вон те устроили практически исход из RHBM и часть скучковалась - вот - вокруг btrfs, уже под другими вывесками, видимо. Деталей не знаю.
Оракл смачно потролил это дело декларя "как редхат, но с этим". А RH видимо наняли по объявлению, закончилось что сбег (хайповатый так то) майнтайнер XFS-а и теперь отвисает где-то рядом с кентом и бтрфсниками, тенденция однако. Видимо гальванизация трупа шла тяжко.
> The Btrfs file system has been removed in Red Hat Enterprise Linux 8.
Пусть еще напишут что все известные файлушники и блочники из их dream team ремувнулись, и теперь XFSников обслуживают нонеймы. Даже хайповатый майнтайнер съ... по причине "боты завалили багами!!!111". Да, это вам не расскажет маркетинг в прессрелизе.
> You can no longer create, mount, or install on Btrfs file systems
> in Red Hat Enterprise Linux 8. The Anaconda installer and the
> Kickstart commands no longer support Btrfs.На лично мое нескромное мнение у редхата что инсталер, что пакетник - лютое УГ. Теперь тренду последовало и управление ФС. Что они там делать будут - хз. Я б на их месте попытался кента перехватить (btrfs-ники уже все при деле). И сделать что-нибудь НОРМАЛЬНОЕ - а не тот #$%ный стыд! Но видимо будет как с пакетником, too little and too late.
Да ладно, врать то. Enterprise Synology так же как и QNAP - ZFS с FreeBSD пользуют. А дурачкам отдают btrfs. Надо же как дифференцировать продукт. Btrfs для лохов под га..но. Под Enterprise ZFS.
ZFS делали серьезные дяденьки для серьезных целей (Конкретно Solaris). Она там обкатана, все у нее в жизни прекрасно и детских болезней в ней нет.
А вот OpenZFS делали другие по другому и с другим подходом.
> ZFS делали серьезные дяденьки для серьезных целей (Конкретно Solaris). Она там обкатана,
> все у нее в жизни прекрасно и детских болезней в ней
> нет.эммм... но это неточно.
> А вот OpenZFS делали другие по другому и с другим подходом.
пока не доказано что этот баг не притащен именно из швятаго соляриса. от сирьозных дядек на сириозных щщах
Во всяком случае он есть в illumos.
Серьезные дяденьки из Sun? Sun - банкрот, Solaris - мертва. OracleZFS - тоже. Дяденьки разбежались, кто на пенсию, кто в другие шараги. OpenZFS - кривая поделка, которую пилит по сути один чувак. Какой-то лаборант.
От того, что они на пенсии, мертвы и банкроты, менее серьезными они не стали
Что значит "не предостоставляет сколько-нибудь значимых преимуществ"? А можете озвучить краткий список возможностей как BTRFS, так и ZFS? Вместе сравним!
Так плюсов в наличии только что-то похожее на raid6 разве что. Зато из минусов для работы надо выделить минимум 2 гига памяти на каждый терабайт хранилища и памяти можно найти применение получше.
крутится фряха с двумя гигами и винтом на 6тб как файлопомока скорость по гигабиту ~125МБ/c
Как дедупликация поживает, сколько подключений, кстати, и вообще что там с параллельной нагрузкой?
Ничего не скажешь, шикарные познания в ZFS. Даже о самом очевидном, изменяемом размере блока, не упомянул. А это, на минуточку, если вы на BTRFS не отключаете CoW, одна из самых важных штук. Просто повальная профанация в области файловых систем.
Так а толку возиться с ней, если она сасает на буквально любых применениях? Я не вижу ни одной причины трогать её даже 12 метровой палкой, и это отличает специалиста от аутиста.
Сколько высокомерия и самонадеянности. На этом профессионализм и заканчивается. Как же все это глупо... будь оно так - с ZFS бы никто дел не имел и не тратил бы на нее столько времени и сил. Ну, удачи специалист!
Так и никто и не тратит. Это чистое безумие, на неё завязываться. Даже не столько по причине технических недостатков.
Чё там, на RPI Model A с 256M RAM будет работать?
Речь о работать, а не слоупочить.
> Чё там, на RPI Model A с 256M RAM будет работать?
> Речь о работать, а не слоупочить.Btrfs - норм работает на таком. Вообще на вид от EXT4 не отличишь особо. А с bg_tree новомодным - он еще и монтируется быстрее чем ext4, совсем уж прикол. Я его даже на роутере с 64 мегами цеплял, достаточно культурно в целом, btrfs (и bcachefs) на уровне структур не супертормоз как ZFS.
В отличие от - может например DUP на sd-карточке разложить что очень способствует тому чтобы система не сдохла от 1 рандомного бэда раз в дохреналион, например. И даже слет блока флеша при внезапном powerloss чаще всего переживает, при налете на это буркнет про csum failed в лог да починит. А ext4 в таком случае ловит шикарнейший фаталити и сразу наповал.
И fsck при старте не надо - что жирный плюс на управляющей штуке: кто там будет разгребать fsck и прочие lost+found? И эникей жать там некому, однако. Так что получает свой пойнт для необслуживаемых и малообслуживаемых систем имхо, делая их более устойчивыми и разворачивая теорвер в более интересную сторону. А заодно чаще всего хайлайтя явные проблемы железа ДО того как это трансформируется в реальные сбои. Узнать о потенциальной трабле из логов лучше чем когда уже отскребаешь управлялку от асфальта в режиме аврала.
Бутер будет. Ему правда будет очень кисло из-за тормознющей SD, но таки будет.
Но я на пост про ZFS отвечал.
> Бутер будет. Ему правда будет очень кисло из-за тормознющей SD, но таки будет.Да нормально работает на самом деле. И флешу cow достаточно удобен на самом деле: in place патчинг для FTL означает крайне нетривиальные RMW+GC, ибо ну вот не умеет флеш на самом деле именно "in place patching" мелким блоком. На уровне его структуры и физики. CoW там лучше в целом. Btrfs к тому же умеет trim - и вон та идея с async trim круто на SD/eMMC @ mmc hci контроллер вписалась.
И между прочим - там еще сжатие есть. Если накопитель тормоз, ЭТО дает кроме всего прочего апгрейд скорости IO, система и проч - неплохо жмется, раза в 2-3.
> Но я на пост про ZFS отвечал.
Ну вот как там в такой конфиге - пусть его юзеры и скажут. Глядя на дизайн zfs мне кажется что это должно основательно тупить, т.к. их дизайну не с чего быть быстрым, а сотен рамы чтобы это вытянуть как раз и нет.
Вот кстати то самое место, где лучше чексумминг иметь, у старых SD-карт ECC примерно около отсутствует.
Новые правда поинтереснее, они уже мало чем от SSD отличаются.
> Вот кстати то самое место, где лучше чексумминг иметь, у старых SD-карт
> ECC примерно около отсутствует.
> Новые правда поинтереснее, они уже мало чем от SSD отличаются.Я бы не стал излишне обобщать. Девайсов, фирмварей и проч - дохрена, и постоянно новые появляются. Кто и что откаблучит - это всегда некое минное поле.
Штуки типа DUP (или тем более RAID1, если было куда) + CSUM здорово улучшают вышиваемость файлухи при отклонениях от идеала. И что важнее, факапы можно заметить на подлете. Скажем учащаюшиеся битые блоки по "csum failed" станет видно ДО того как девайс по всей площади осыпется в труху. А на EXT4 каком это замечают когда там уже совсем фаталити, так что оно и не смогло работать дальше. Но там к тому моменту может такой трешовник быть - что чинить уже нечего и спасибо если хоть самое ценное хотя-бы частично восстановится.
ФС с чексумами сильно улучшают диагностируемость железа и даже в общем то и глюков софта порой. Идея в том что что бы ни вызывало глюк, оно не знает как считать чексумы а то что оно вклинится в окно между формированием данных и счетом чексуммы - не так уж и вероятно и чаще всего чексумы смогут спалить даже и это тоже. Потому что отъедет. Не на 100% гарантия - так что обещание что данные не будут испочены может быть профукано. Но реально хайлайтит проблемные железки на ура.
Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?нет. но сервера, например, без ecc не рассматриваю. и давно решил, что и домашний компьютер при следующем апгрейде будет с ecc памятью.
не потому, что ecc исправляет ошибки, это на самом деле не главное.
главное, что ecc детектит сбои, и можно отбраковать проблемные модули памяти до того, как это вызовет пробемы.в сравнении со стандартным «что-то прога сегфолт выдала, может библиотека кривая, а может быть космические лучи, или всё-таки выключить комипьютер и на сутки запустить мемтест» это просто гигантский шаг вперёд.
Э, да у вас проблемы с надёжностью.
У меня десктоп с ECC-памятью лет 8 уже как.
Может поэтому мне никакие ZFS и не упёрлись :)
> Э, да у вас проблемы с надёжностью.
> У меня десктоп с ECC-памятью лет 8 уже как.
> Может поэтому мне никакие ZFS и не упёрлись :)А корректность работы проца, чипсета, шин, шнурков, накопителей и проч - гарантируется любимым российским методом - "на авось". Я все правильно понял в этой чудной схеме?
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?Представляешь, даже летом можно походить в горах - или даже сунуться в коллектор. Более того - учитывая хлипкость современного железа, где в погоне за скоростью и ценой профачили надежность и стабильность на всех мыслимых уровнях - ну ты еще скажи что страховочный трос на высоте "летом" ни к чему, и каску на стройке тоже одевать - это лишнее, под ней череп потеет. Видимо, будет намного лучше если с высоты какой-нибудь камешек его прошибет насквозь - зато, вот, не жарко.
И да, при чём тут ФС с чексуммами - опять явная реклама.
dm-integrity мало?
> И да, при чём тут ФС с чексуммами - опять явная реклама.
> dm-integrity мало?не смотрел внимательно, но обеспечивает ли dm-integrity консистентность данных?
случаи, когда накопитель сказал, что записал данные, а после отключения оказывается, что нет — он читает пусть и валидные, но данные прошлой версии — совсем не редки, увы. в многодисковых конфигурациях это может сделать больно. да и в однодисковых возможны сценарии потери данных.zfs закрывает и этот случай тоже. ну и, как побочный эффект, raid5 write hole тоже закрывается.
Это да. Неказистый RAID5 write hole ловким движением превратился в элегантное read zero hole.dm-integrity хранит журнал и метаданные отдельно от данных, так что должно быть ок.
> И да, при чём тут ФС с чексуммами - опять явная реклама.Очень странно упоминать ФС с чексумами в топике про ФС с чексумами. Где чексумы одно из достоинств дизайна и аргумент "за".
> dm-integrity мало?Файлухи с чексумами менеджить сильно удобнее чем этажерку из этих кусков крапа. А ты можешь на этих костылях прыгать если хочешь. Но без моего участия. Мне как-то device add/device remove - с прозрачным увеличением/уменьшением места по сути 1 командой - нравится сильно больше. Я хочу видеть управление вот так, а не вон тот кошмарик.
И да, снапшоты тоже полезны, например, для операционки, чтобы как в виртуалке - в случае факапа например апгрейда системы просто откатиться да попытаться еще раз. Без реинстала всей оси и проч на полдня. А у тебя вон то не получится. Можно конечно и это отрастить в той этажерке, но если захочется что-то переконфигурировать, скажем, размер ФС увеличить - не спятить при этом будет довольно тяжко. Наслаждайся этим сам, а я свой выбор сделал. И хотя это не ZFS, они были первыми кто это придумал - и у них был нефиговый пойнт.
А вы, видно, неплохо так развлекаетесь. В таких условиях, даже BTRFS придется несладко.
btrfs кстати кое-как работает... И учитывая что левелинг в старых SD надо искать, некоторый смысл имело.
То же самое с CF в совсем мелкой эмбедовке, которая ещё хуже распи. Но туда конечно и бтр уже не влезает, приходится делать слой левелинга на ubifs.
С другой стороны в новых самсунговских SDXC левелинг есть, и на новых RPi уже можно особо не заморачиваться.
Основная проблема в BTRFS - это просто конский WA. Причина того, почему ZFS будет работать плохо или не работать вообще - это ARC. С этим уже ничего не сделаешь.
WA да, у BTRFS действительно конский, проверено на SAN.
Ещё отдельная проблема с трекингом свободного места, но она хотя бы решаема вариантом одна FS - один "раздел".
> WA да, у BTRFS действительно конский, проверено на SAN.Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов?
> Ещё отдельная проблема с трекингом свободного места, но она хотя бы решаема
> вариантом одна FS - один "раздел".Это расплата за продвинутый дизайн и удобный менеджмент, у медалей 2 стороны. Если у вас есть возможность сжатия, рефлинки, снапшоты, возможность сохранять в РАЗНЫЕ схемы избыточности и проч - ответ на вопрос "сколько места" становится ... значительно интереснее.
Появляются забавные факторы.
- Насколько сожмется? Вы это знаете заранее?
- Насколько блоки совпадают - и будут совпадать далее?
- В какой схеме в будущем запросят новые блоки? Это переключаемо в run time и ничем не грозит, можно даже не рестрайпить а заказать новые дефолты для НОВЫХ записей, тогда то что уже записано останется в той схеме как было. Это совершенно валидно в таком дизайне. Это же делает возможной конверсию типа RAID на ходу, по примерно той же технологии. С cow нет причин почему бы данные разрушились. Даже при крахе во время этого действа. И ему даже позицию конверсии трекать не надо при этом.
- А также прочие приколы типа снапшотов, метаданных/tail packing (метаданные могут иметь иную схему хранения чем данные, "хвосты" или мелкие файлы - будут в этой схеме). Откуда заранее знать data/metadata ratio и проч?
>> WA да, у BTRFS действительно конский, проверено на SAN.
> Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов?Смешанный.
> Это расплата за продвинутый дизайн и удобный менеджмент
Не знать, сколько _реально_ в FS осталось свободного места - это да, мегаудобнейший дизайн и наиэффективнейший менеджмент. Честно - одна из самых веских причин обходить стороной. Потому что внезапный отказ в записи - это почти гарантированно потеря данных с любым софтом ныне.
> - Насколько сожмется? Вы это знаете заранее?
> - Насколько блоки совпадают - и будут совпадать далее?Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся" и "совпадают".
Если удастся записать больше - хорошо, но ни в коем случае не меньше.> С cow нет причин почему бы данные разрушились
Конечно нет, ZFS не даст соврать. И ищи потом свищи, где у тебя в этой каше был оригинал данных, он там на весь диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно, и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.
> Смешанный.Может означать все что угодно. Однако нехило бы описать что и как измерялось, по сравнению с чем, и указать какие-то детали.
>> Это расплата за продвинутый дизайн и удобный менеджмент
> Не знать, сколько _реально_ в FS осталось свободного места - это да,Ды ты в современной системе и сколько RAM свободной - де факто не знаешь. Можешь посмотреть как в линухе аллокация памяти сделана по дефолту, с оверкомитом и проч. Идея кстати примерно та же самая. Но ты конечно можешь у себя отрубить оверкомит... только тогда сильно меньше программ сможешь запускать при прочих равных. Почему-то.
А прикинь, файлуха может не знать заранее что я рефлинкну вон тот 3-терабайтный образ. Смотри, мы начинаем с 3Тб файлом и 5Тб хранилкой. Вроде бы 2 Тб места примерно. Делаем пару рефлинканутых "копий". Опа, у нас как бы 9 терабайт - на 5 тер места. Реально конечно там 3 терабайта + отличия. Но де факто это оверкомит и "оверселл". И откуда б заранее знать насколько рефлинкнутые копии разъедутся? Захотят - станут независимые. Или останутся почти идентичными. С сжатием - аналогично. И так далее.
> мегаудобнейший дизайн и наиэффективнейший менеджмент. Честно - одна из самых веских
> причин обходить стороной.Ну да, ну да, в бак с топливом "боинга" на лету неудобно светить фонариком и оценивать на глаз, приходится датчикам доверять, плюс-минус цать литров.
Ващет файлухи на 100% забивать - не очень удачная идея в целом из-за жуткой фрагментации. Так что в нормальном случае это не проблема. При том если btrfs после этого можно попробовать отдефрагать, в случае сабжа - получится убер-тормозной пул с которым вообще хз что делать. Но вообще-то такая же фигня даже и из ext4 и xfs получается. У ext4 даже дефраг есть но он видите ли не умеет агрегацию свободного места и вообще базовый весьма.
А, да, EXT4 кстати - вообще идиотская ФС. Например совсем не умеет деаллокацию директорий. Если в дире одно время отращивалось 100500 файлов и дира вымахала до эн мегз - мало того что дира останется эн мегз навечно! Кроме этого - даже если там ща 100 файлов, операции с этой дирой тормозят как будто там все 100500 на месте. Такая вот скалабельная, крутая фс - которая даже деаллоккацию дир не могет. И которой цук номерков на иноды может не хватить. И эти люди тут еще юродствовать смеют на тему сабжа.
> Потому что внезапный отказ в записи - это почти гарантированно потеря данных
> с любым софтом ныне.Как там поживает деаллокация дир в EXT4 или ограничение на число инодов? А, ничо, эти копролиты - нормуль, не жмут?
> Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся"
> и "совпадают". Если удастся записать больше - хорошо, но ни в коем случае
> не меньше.Оно что-то такое видимо и выдает как оценку для доступного места. Но реально ессно возможны варианты. Кроме того...
...у ФС есть метаданные. Вот смотрите: кто-то даже делал супер-архивер, который попытался взять приз на конкурсе сжатия. Идея была простая:
- А можно сохранять в несколько файлов?!
- ОкеЙ, сохраняйте!Ну чувак и читал данные исходного файла. Разложил прочитанные данные по именам файлов в дире. И вот - обана! - смотрите дети, идеальный архивер! Суммарный вес файлов - ноль! Данные же в именах хранятся, зачем в файл что-то писать. Сумма размеров файлов - вообше ноль.
Вот только приз ему кажется не дали. Да и вообще - если попробовать так архивировать, можно заметить что в принципе можно догнаться до точки когда формально на ФС аллоцировано 0 байтов в файлы, но записать почему-то не получается. А как вы собрались заранее оценивать размер метаданных и соотношение оного VS данные - кто б его знает. Для ФС с tail packing и inlining мелких файлов - это как бы аргумент.
>> С cow нет причин почему бы данные разрушились
> Конечно нет, ZFS не даст соврать. И ищи потом свищи,Ну, вообще, если попортилась копия, копии, да еще быстро упавшая лицом на тот кулак 2 раза подряд - это еще ухитриться надо. А с твоим EXT4 педальным ты и осыпон половины файлухи не заметишь. И таки глядя на коллекцию BadHardware отловленого btrfs я имею сказать что "it works!" и я буду предпочитать такую диагностирумеость и верификацию работы моих систем и далее. Это спасает от множества дурачких приключений и непоняток.
> где у тебя в этой каше был оригинал данных, он там на весь
> диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно,Ну вот вообще ниоткуда не следует. Если подзабить и активно поюзать даже тот же EXT4 - тупить он начнет весьма ощутимо, особенно на механике.
> и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.Я и с btrfs'а вытащу, при том в отличие от твоего хексэдитора - прям встроеным альтернативным парсером. Да еще - имея под рукой ТРИ копии суперов, много разных точек входа в иерархию деревьев, ибо GC ж не прибивает более старый вид сразу и оно энное время живет. Это повышает шансы что основной объем метаданных зацепится без урона вообще. Особенно учитывая что хранится даже на 1-дисковом стораже с DUP, а на более приличной конфиге и как RAID1 (можно даже c3/c4, если девайсов много). Я как-то предпочту не натыкаться на мануальный парсинг данных, чем упражняться в нем, при прочих равных. И я это говорю как датарек-любитель, способный поболтать на равных с себе подобными. Вооон там в советах, я изобрел способ gumanzoy по ресету и рескану за несколько лет до него. Правда я скрипты не делал - тупо oneliner "по ситуации" на машине запускал.
> Ну да, ну да, в бак с топливом "боинга" на лету неудобно светить фонариком и оценивать на глазНу, знаешь, если в боингах будут такие же датчики, как в бтрзфсах, то я лучше на них летать перестану.
это "трухлявое дерево" спасло массив на 40 тб после добавления ошибки в драйвере в ядре, недопустив повреждения данных и отключив массивтак что на личном опыте использования могу сказать что ты звездишь
Сказки опеннета.
loshok сходи на kernel.org[ 287.137901] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137909] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137912] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137914] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137916] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137919] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137921] aacraid: Host adapter abort request.
aacraid: Outstanding commands on (10,0,0,0):
[ 287.137924] aacraid: Host adapter abort request.
Сказки тут:
> это "трухлявое дерево" спасло массив
именно оно и спасло, при загрузке старого ядра данные остаются целыми, но если произвести модификацию данных на новом ядре, то портятся, все ext4 разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив свою целостностьтак что давай дальше БибаБоба смеши людей
> а BTRFS не дал этого сделать, проверив чексумы, сохранив
> свою целостностьА ранее ты писал:
> недопустив повреждения данных и отключив массивЫ?
> так что давай дальше БибаБоба смеши людейАха, давай смеши дальше, сказочник опеннета.
массив был перемантирован в режиме для чтения, потому что операции записи были невозможныи это все было выполненно ядром и BTRFS автоматически
так что не так, Куклачев?
> массив был перемантирован в режиме для чтения, потому что операции записи были
> невозможны
> и это все было выполненно ядром и BTRFS автоматически
> так что не так, Куклачев?И давно errors=remount-ro отменили?
>> массив был перемантирован в режиме для чтения, потому что операции записи были
>> невозможны
>> и это все было выполненно ядром и BTRFS автоматически
>> так что не так, Куклачев?
> И давно errors=remount-ro отменили?так EXT4 думал что у него все хорошо
Чо? Ядро выплюнуло ошибки контроллера, ext4 там уже ничего думать не может.
>>> и это все было выполненно ядром и BTRFS автоматически
>>> так что не так, Куклачев?
>> И давно errors=remount-ro отменили?
> так EXT4 думал что у него все хорошоНу дык, он Титаника напоминает - до последнего оркестр играет и проч. Но потом все же может потонуть.
> все ext4 разделы побились, а BTRFS не дал этого сделатьBTRFS спас EXT4 разделы? Что я читаю?
> именно оно и спасло, при загрузке старого ядра данные остаются целыми, но
> если произвести модификацию данных на новом ядре, то портятся, все ext4
> разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив
> свою целостность
> так что давай дальше БибаБоба смеши людейЧексумы забавная штука - они "до кучи" зарубают множество багов железа и софта. А фаны EXT4 - предпочитают следствия из законов Мерфи - как то: "если вам кажется что дела идут хорошо, возможно вы просто чего-то не заметили".
Например дырочку при чтении дырочки из файла.
> Например дырочку при чтении дырочки из файла.Субъективно - на 1 этот факап за всю жизнь я видел не менее ДЮЖИНЫ прецедентов выгрузки блочными девайсами какой-то трухи юзерам - и даже лично мне.
Учитывая что для вот этого факапа надо было еще и извратиться, а вон то - вообще САМО разваливается, на флешатине просто за факт приближения к лимиту износа - ну, знаете, я предпочту знать истинное состояние дел с чексумами. И не, ваши dm, md, lvm и проч вы там сами и используйте, имхо. Если в zfs нужда в именно таком менеджменте девайсов еще притянута за уши, ибо ничего принципиально иного не делает, то вот btrfs и bcachefs попользовались на всю катушку возможностями которые это дает - и это было круто.
А еще лично мне нравится как логика self heal в btrfs с ремапом взаимодействует: репайрит плохую копию из хорошей, что при io error что при отгрузке трухи. В любом случае проблема починена а этот факт залоггирован. А не вон тот позор.
ZFS плоха в частности именно этим монотонным унылым пиаром - на уровне пониже начинают верить, что оно действительно волшебное. А с технической стороны - пока оно с системным кешем не интегрируется, для обычного юза непригодно, разве что для выделенных NAS.
> ZFS плоха в частности именно этим монотонным унылым пиаром - на уровне
> пониже начинают верить, что оно действительно волшебное. А с технической стороны
> - пока оно с системным кешем не интегрируется, для обычного юза
> непригодно, разве что для выделенных NAS.Просто ненужно его юзать с линуксом. И будет всё отлично. В родной иллюмус нет проблем с интеграцией кеша.
> ZFS плоха в частности именно этим монотонным унылым пиаром -Ну, блина, я его на Btrfs'е таки оценил - и могу подтвердить что чексумы способствуют отлову кривого железа. При том чаще всего ДО того как это в фатальные проблемы эскалирует. А что делать? Факты штука упрямая, мой опыт - вот такой. И чексумы в ФС делают минимум допущений о конфиге, чем оно и хорошо - работает везде.
Врать не мешки ворочать... Ммм диски...
О. а у тебя массив 40Тб на zfs? А зачем? Какая нагрузка? Что в прикладе? Почему zfs? А то твои коллеги так и не осилили ответить на эти вопросы.
у меня есть массивы и побольше.почему zfs — в первую очередь потому что чексуммы + merkle tree (плюс это всё работает в связке с raidz/raidz). также востребованы снапшоты, возможность выносить метаданные на ssd в отосительно свежих версиях; возможность сделать большой размер записи; дедупликация.
мои варианты использования:
- тупая файлохранилка, отдача по http/smb/nfs/…
куча hdd, метаинформация на ssd, снапшоты;
- то же самое для бэкапов образов виртуалок/физических хостов
аналогично, плюс дедупликация;
- хранилище в проксмоксе
ssd, zvol (блочные устройства для гостевых систем, к которым применимы все гарантии целостности и конситентности zfs).
>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных.А, ясно, жалуются фрибздуны.
>>> Сижу на BTRFS с 2012 года и не потерял ни единого бита информации. А на ZFS постоянно жалуются на потерю данных.
>>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных.
> А, ясно, жалуются фрибздуны.А, ясно, опять нам пишут Этодругое-ниды.
>> Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации.
>> А на BTRFS остоянно жалуются на потерю данных.
> А, ясно, жалуются фрибздуны.Ты только сейчас это заметил? Ну понятно что им обидно - btrfs даже на маздайке уже есть, а у них только дырка от бублика^W файла какого-то, копированого дважды :)
Ну я ни на ext2, ни на ext3 данные не терял - какие выводы необходимо сделать из этого факта?
вы наняты!
просто дай мильён баксов, а то опять работать заставляешь
> вы наняты!Или я просто звИзд0б0л. Или этих данных у меня было 2,5 байта - поставил на виртуалку, выключил\включил - ничего и не потерялось. Или... да много чего "или".
Абсолютизировать свой, скорее всего, нерепрезентативный личный опыт - невеликого ума занятие.
Ну почему же, просто не стоит говорить за всех. Это невеликого ума занятие. Вот лично я испытал куда больше повреждений ext4, чем 100% прочих пользователей ext4. И в процессе экспериментов, и в процессе тестирования, и в процессе использования в самых разных условиях. Даже обнаружил, что существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала, при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт достаточно много времени (ещё и несколько раз перезапустится в процессе). А вот с xfs у меня терялись данные, например, хотя большинство её поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не стоит.
>[оверквотинг удален]
> и в процессе использования в самых разных условиях. Даже обнаружил, что
> существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но
> потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за
> новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала,
> при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт
> достаточно много времени (ещё и несколько раз перезапустится в процессе). А
> вот с xfs у меня терялись данные, например, хотя большинство её
> поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся
> ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не
> стоит.Уф. Оценить "репрезентативность выборки" и "релевантность условий" на основании собственного опыта примерно "нельзя". Как соотносятся "надежность ФС" на физическом сервере в кладовке под нагрузкой "аждымицца!" и надежность той же самой ФС на виртуалке в ЦОДе в составе LB-кластера с автомасштабированием? Да никак не соотносится - в одном случае может регулярно сыпаться с последствиями, в другом - стабильно работать годами.
В общем случае - "надежность работы ФС" оказывает не то, чтобы большое влияние на надежность хорошо спроектированной _системы_. Ну вот заглючил на СХД два месяца назад FC-порт - расфигачило SQL-сервер с 10 Тб данных - повлияло это на работу системы? Да нет, автоматом переключилось на другую геореплику, пересоздали виртуалку, залили бэкап, догнали лог - и даже не уверен, переключили ли нагрузку обратно. Чем\как бы тут помогла btrfs, fsck или другая абэвэгэдэ?
Не то, чтобы мне было "совсем пофиг" на "надежность ФС" при проектировании ИС - но "примерно пофиг", да. Даже в отдельную строчку модели угроз не выделяем идет в составе "вероятность выхода из строя узла" или как-то так.
Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт, рано или поздно.
> Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами
> (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт,
> рано или поздно.Ну, примерно то же, что и в этом тредике с ZFS и чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы. Пойду бэкап поднимать - а вам с верой в "надежные-фс-и-чексуммы" ну... удачи, что ли.
Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов (и во многих случаях избежать потери данных). Могут быть даже ситуации, когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность). До тех пор, пока по какой-либо причине не посыпется сама фс, тут уже как повезёт.
> Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это
> незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов
> (и во многих случаях избежать потери данных). Могут быть даже ситуации,
> когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность).
> До тех пор, пока по какой-либо причине не посыпется сама фс,
> тут уже как повезёт.Да - но так же и определенные недостатки в виде пригодности COW-семантики к ряду нагрузок. Плюс, если говорить за энтерпрайз и коммерческий саппорт - то тут будут играть роль дефолты базовой ОС и непосредственные рекомендации вендора ПО. Опять же, общий дизайн системы... я более, чем уверен, что facebook сделал правильный выбор... для facebook'а, и совершенно убежден, что пытаться повторять куски его технических решений у себя мне не следует :).
Как-то так.
Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у себя в проде - это высокая гарантия качества этой файловой системы при любом применении и нагрузках! В самом деле, как дети...
> Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у
> себя в проде - это высокая гарантия качества этой файловой системы
> при любом применении и нагрузках! В самом деле, как дети...Охтыж. Знаменитая "экспертиза opennet" in action. Или система спроектирована таким образом, что на сохранность данных каждой конкретной ноды настолько "пофиг", что просто "пофиг" - а вот дедуп экономит вполне реальные деньги. Пуркуа бы не па...
Мне следовало добавить плашку "Сарказм"?
Капсом. И джва раза - для тех, которые "Я" :)
Каюсь. Не распознал... видимо, из-за того, что крепко-крепко приболел. Так себе "отмазка", но хотя бы является правдой.
> Ну, примерно то же, что и в этом тредике с ZFS и
> чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы.А что тут странного? Чексуммы — не серебряная пуля, ошибки в реализации фс они, очевидно, не могут исправить.
Зато ошибки в железе/прошивках они обнаруживают, а зачастую и дают исправить
Ахтунг, чексуммы научились исправлять баги в прошивках!!!111
> Ахтунг, чексуммы научились исправлять баги в прошивках!!!111исправлять баги — нет, конечно.
испралять data corruption, вызванные (в том числе и) багами в прошивке за счёт чексум и избыточности — да. и одной избыточности тут недостаточно, в случае с raid 1, например, мы можем только узнать что копии расходятся, но не можем сказать какая верная. то же самое и с raid 5.
raid 6 теоретически может исправить ошибку, но только пока он не в degraded состоянии.у zfs таких ограничений нет, всегда можно сказать верна ли запись на конкретном диске или нет (и, более того, за счёт merkle tree можно сказать актуальная она или нет; если нет, то можно откатить фс в предыдущее консистентное состояние)
> в случае с raid 1, например, мы можем только узнать что
> копии расходятся, но не можем сказать какая верная. то же самое
> и с raid 5. raid 6 теоретически может исправить ошибку, но только пока он не в
> degraded состоянии.Во, edo понял трабл - и чем райд+чексум лучше чем просто raid. Но в размазанном на layer'ы дизайне оно, вероятно, в self heal вообще не смогет. Инфо на стыке layer'ов потеряется - и упс, то что btrfs делает в крейсерском режиме, вообще не требуя конфигурации, вон там - жуткий рокетсайнс - если возможно вообще. Пусть этот свистун и пользуется такими технологиями сам.
> можно сказать актуальная она или нет; если нет, то можно откатить
> фс в предыдущее консистентное состояние)Btrfs для трека актуальности generation использует, но это в целом не мешает чексумам работать и делать - ну вот то что и должны. Так что наловилось некоторое количество кривых экспонатов. И при таких фактах свистящий трон выглядит хиловато...
Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же какое счастье для тебя.
О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя. Так что, идея хешировать только метаинфу вполне здравая. А если данные повредятся по причине неисправности железа, никакие проверки тебе не помогут в итоге.
Прошивка носителя ничего не знает ни о ФС, ни о данных, ни о метаданных. Это днище. Если на Btrfs данные окажутся битыми, об этом разу будет известно. А ext4/XFS при рассыпании носителя, молча схавают это и дальше молча продолжат работать, как ни в чем ни бывало (silent data corruption). Данные тоже должны хешироваться, что есть в Btrfs.
Только silent data corruption не имеет ровно никакого отношения к повреждению носителя. Которое прошивка замечательно обнаружит после цикла самодиагностики (или даже сразу при обращении). Гораздо большая проблема это повреждение данных в процессе их записи, консистентность обеспечить может быть трудно даже при при наличии политики безумных повторных проверок. И файловые системы с нездоровым оверхэдом тут не особо помогут (а при совмещении с "лучшими практиками" ситуация становится ещё более абсурдной). Способность бтрфс сдохнуть и невозможность восстановления хоть чего-нибудь при серьёзных повреждениях, фактически множит на нет все её преимущества.
Поврежденные данные должны чекаться на уровне ФС. При записи должна быть сгенерирована хэш-сумма и потом периодически эта хэш-сумма должна сравниваться со сгенерированной хэш-суммой при скрабе. Прошивка тут ничем не поможет. Она не знает ни о ФС и тем более не имеет к внутренностям ФС. Btrfs давным-давно надежно и не дохнет на нормально работающем железе. А если и сдохнет, то данные восстанавливаются из бэкапа. Бэкапы надо делать в любом случае, даже если создадут супер-пупер надежную ФС. Эта ФС не спасет от пожара в хате или от сдохшего БП, который пропустит 220 вольт и сожгет все носители.
Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику дисков (к примеру, при подключении через китайский переходник), то, может быть.>на нормально работающем железе
на нормально работающем железе никогда не понадобится ничего сложнее ext4.
На большом масштабе подход с чексуммами срабатывает:
https://www.cs.toronto.edu/~bianca/papers/fast08.pdf
https://indico.cern.ch/event/13797/contributions/1362288/att...Вопрос в оправданности в конкретном случае.
> Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные
> операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику
> дисков (к примеру, при подключении через китайский переходник), то, может быть.Это может сказать только человек не эксплуатировавший ФС с чексумами в достаточном объеме. А те кто это пробовал - таки, вот, наловили глюкавых железок и спасли немало фс от фатальных разлетов, срубив проблему на подлете - и считают иначе, соответственно. Хороший пример что незнание - сила. В плохом смысле слова.
>>на нормально работающем железе
> на нормально работающем железе никогда не понадобится ничего сложнее ext4.Осталось еще вселенную с этим нормальным железом найти. Потому что в этой вселенной - даже энтерпрайзные SSD осыпаются. Особенно если ими подпереть как кешом более медленные хранилки.
Упоминание ссд тут очень характерно и показательно на самом деле.
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя....которая у SSDшников, флешек, sd карт и прочей флешатины зачастую совсем не прочь отгрузить какую-то левую труху, особенно при приближении к лимиту записей. Очень доставляет любителям bcache (не путать с bcachefs), которые это юзают в нагруженых конфигах ради перфоманса - и потому нередко приближаются к лимиту записей даже с энтерпрайзными девайсами. После чего - ну, btrfs то красиво орет в логи на csum failed заранее, они вылезают с вопросами, и если не очень тупят - успевают заменить девайс(ы) ДО того как все разлетится окончательно. И по крайней мере не могут сказать что их не предупреждали о факапах их хардвара.
А вот фанов EXT4 и прочих XFS в этом месте по сценарию ВНЕЗАПНО зашибает роялем. И они вылезая из дырки удивленно - что за фигня? Где мои данные?! А там раз - труха на половине файлухи уже.
> Так что, идея хешировать только метаинфу вполне здравая.
Ну может тогда данные и хранить не стоит? Раз уж они не нужны. Ext4 все равно о их сохранности не парится, особенно без полного журнала (который тормозной как улитка из-за дублирования записей).
> А если данные повредятся по причине неисправности железа, никакие проверки
> тебе не помогут в итоге.1) Таки помогают.
2) Прекрасно чинят битую копию из избыточной.
3) Это еще и дружественно к ремапу сбойных секторов фирмварой накопителя.А ext4 будет насиловать нечитаемый сектор до упора. Данные же хочется, больше взять неоткуда, а запись в этот сектор чтобы его еще и ремапнуть - можно не дождаться. Скорее, если не повезет - можно искусственно догнать read error rate до потолка, накопитель решит что ему плохо, уйдет в safe mode - и вот тут вам уже СЮРПРИЗ! И да, все это шоу - из-за 1 гребаного бэда который можно было ремапнуть и забыть о нем.
И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате? С чексумами то ответ тривиальный. А сделать из EXT4 райд с чексумами ну не то что совсем нельзя, но админ предпочтет застрелиться при нужде это менеджить.
> А ext4 будет насиловать нечитаемый сектор до упора....
> И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате?А разве не очевидно, что правильная та, которую один из накопителей прочитал без ошибок?
Вроде об этом было исходное утверждение.
>> И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало.
>> И чего? Какая правильная в результате?
> А разве не очевидно, что правильная та, которую один из накопителей прочитал
> без ошибок? Вроде об этом было исходное утверждение.Так сложно понять что фирмвари (в основном у флешастых штук) в последнее время взяли моду возвращать при чтении какую-то труху - без отлупа IO error при этом? И вот у вас 2 разные копии - а теперь попробуйте угадать которая из них была правильная!
С чексумами то это как 2 байта переслать - где совпало, тот девайс и нормальный. А вон тот, гамнюк, гонит, вот ему перезапись этого блока. А если такое часто - он, наверное протерся/сыпется/кривой и это вообще лучше заменить ASAP. При этом по крайней мере известно что проблема есть. А на какомнить EXT4 данные будут рандомно факапаться, никто ничего не заметит пока что-то не навернется как следует, в заметном виде.
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя.Или не прекрасно, личный пример факапа я уже размещал в этом обсуждении.
> Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и
> продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности
> данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же
> какое счастье для тебя.Да нет, это вы на локалхосте не подозреваете, что data integrity может контролироваться как на уровне выше, так и ниже ФС. Объясните, нахрена мне например развертывать ноды кассандры поверх btrfs с её мейджик чексуммами, м? Вот чтобы что?
А кластеризованный postgres развернутый поверх raid6 в btrfs нуждается? Ох, бида - бегу переделывать. Заодним на бэкапах сэкономлю! Счастье то какое! Спасибо, друк!
То что выше - костыли. То что ниже - не data integrity, а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у меня крутится на Btrfs с отключенным COW). Ну так вот, в БД целостность данных контролируется и обеспечивается этой же самой БД, а не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу должна наботать и ФС, ибо она по сути тоже БД.
Сейчас бы крутить PostgreSQL на BTRFS...
> То что выше - костыли. То что ниже - не data integrity,
> а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС
> и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у
> меня крутится на Btrfs с отключенным COW). Ну так вот, в
> БД целостность данных контролируется и обеспечивается этой же самой БД, а
> не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу
> должна наботать и ФС, ибо она по сути тоже БД.Ага. То, что выше - костыли, postgres - выше ФС, postgres это хорошо, по этому ФС должна быть как postgres. "Л" - логика! Я понял.
Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что в postgresql чексумминг на уровне страниц надо включать отдельно? Впрочем, о чем это я, право слово. "Поздравляю тебя, Шарик - ты..."(ц)
Вопросы _когда именно_ проверяются включенные чексуммы в postgresql, что происходит при выполнении резервного копирования (С мастера, кстати - или с реплики?), поддерживается ли этот сетап энтепрайз-бэкапилками и тэ дэ - оставляю для самостоятельного изучения. Рекомендую провести его ДО факапа, а не после - но тут уж хум хау.
> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что
> в postgresql чексумминг на уровне страниц надо включать отдельно?Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже вот фича такая есть.
>> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что
>> в postgresql чексумминг на уровне страниц надо включать отдельно?
> Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус
> еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы
> дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже
> вот фича такая есть.И какое отношение этот спич имеет к истории Шарика выше, который вместе с COW, роняющей перформанс БД (mvcc субд + cow ФС, м-ммм!) отключил чексуммы на ФС, а в БД - внезапно - не включил, и рассказывает всем про супер-уровень-защиты-волосы-стали-длинными-и-шелковистыми, м?
А если "никакого" - то может лучшие собаководы расскажут, куда в таком сетапе ставить btrfs (Или не btrfs?), где включать чексуммы, как с этим взаимодействует репликация (Streaming или logical? Или может вообще не включать - двух контрацептивов заглаза?), к чему цеплять EMC Avamar (Или не цеплять? Защищено ж все!) - ну и что сделать, чтобы этот чудо-сетап в реальной жизни отставал от mssql на фуууу! немодной ntfs хотя бы процентов на 20, а не каквсигда?
> Да нет, это вы на локалхосте не подозреваете, что data integrity может
> контролироваться как на уровне выше, так и ниже ФС.На уровне ниже фс, внезапно, случаются факапы.
На уровне выше фс тоже не всё так просто, обычно софт ожидает консистентность от фс (например, что версия файлов данных бд соответствует версии wal).
>> Да нет, это вы на локалхосте не подозреваете, что data integrity может
>> контролироваться как на уровне выше, так и ниже ФС.
> На уровне ниже фс, внезапно, случаются факапы.
> На уровне выше фс тоже не всё так просто, обычно софт ожидает
> консистентность от фс (например, что версия файлов данных бд соответствует версии
> wal).Да. И уровень ФС, как мы видим, от факапов нифига не застрахован. Более того, лишнаяя сложность не бесплатна и сама по себе повышает вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не работают в три раза лучше одного, да?
> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован.
> Более того, лишнаяя сложность не бесплатна и сама по себе повышает
> вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не
> работают в три раза лучше одного, да?с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность у фс.
а факапы с потерей данных были с у ext4, и у xfs, про btrfs я вообще молчу
>> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован.
>> Более того, лишнаяя сложность не бесплатна и сама по себе повышает
>> вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не
>> работают в три раза лучше одного, да?
> с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность
> у фс.
> а факапы с потерей данных были с у ext4, и у xfs,
> про btrfs я вообще молчуНу, теоретически - если "забесплатно" или "очень-очень-дешево", то конечно "ДА!!!". Если дорого, сложно и с COW в нагрузку - то уже ХЗ. Хватит ли чексуммы метаданных в качестве компромисса - тоже вопрос.
Ответ на это все - varies от системы к системе. Как-то так.
Ну вот ZFS нули в файлах не хавала, да?
Допустим, полностью вы их не теряли. Но частично - наверняка! Правда, выяснить это без csum никак нельзя. Разве что на фотографиях или аудиозаписях. Так что csum - это необходимость, а не чей-то каприз.
> Допустим, полностью вы их не теряли. Но частично - наверняка! Правда, выяснить
> это без csum никак нельзя. Разве что на фотографиях или аудиозаписях.
> Так что csum - это необходимость, а не чей-то каприз.Чем ситуация "я никогда не терял данные" отличается от ситуации "данные потерялись, но НИКТО НИКОГДА об этом не узнал"? А если нет никакой разницы...
Вы и сами ответили на свой вопрос.
> Вы и сами ответили на свой вопрос.Доказательство наличия битов шредингера (Зависят от ФС наблюдателя - у btrfs все потеряно, но нашлось и даже восстановилось (но это не точно - см. казус с ZFS) - у любителей xfs ничего и не терялось - но несомненно ВСЬО пропало) через "аксиому суслика" - никто его не видел, но все знают, что он - ЕСТЬ. Кэк-спертиза opennet as is.
ZFS надежная как скала. OpenZFS не особо.
И как в скале хранятся данные? Высекаете?
Надёжная только в режиме использования, как ПЗУ.
Ну так поставь на битый HDD всё сразу и потеряешь, лмао
Какое количество резервных копий на других физических устройствах с другими файловым системами вы использовали, чтобы не потерять свои данные на btrfs? :)
Резервные копии на 2 отдельных отсоединяемых HDD и тоже на Btrfs. Дальше что? Делать резервные копии ты должен в любой случае, какая бы супер-пупер надежная ФС ни была бы. Малоли, какой-нибудь клоун внесет в нее какой-нибудь коммит с багами и тю-тю твои данные.
Вот это
>2 отдельных отсоединяемых HDD и тоже на Btrfsназывается "держать все яйца в 1 корзине".
и фактически их нет, зао ты успешно тратишь время ну глупости.Толку от тех копий, если они рассыпаться будут при подключении, например? Не надо тут утверждать, что этого не случится. Чтобы этого не случилось, надо хотя бы знать основы криминалистической работы с данными, и регулярно их практиковать. Но только когда у тебя на руках десятки терабайт данных, которые срочно надо восстановить и привести в норму, на заботы о безопасности в любом случае просто нет времени.
У меня Btrfs уже 11 лет не сыпается ни разу, с какой стати она должна рассыпаться сразу на всех 3 копиях одновременно? :) Типо, если у меня каждая копия будет с разными ФС, это спасет от рассыпания? Диверсификция - это дно.
Спасёт, если причина в баге ядра или в баге специфического юзеспейса.
Я не говорил, что буду бэкап подключать на том же ядре, на котором крякнулся основной носитель)
Слишком много "если" и никаких гарантий, что на другом ядре и ОС этого не случится. Даже если это старое ядро, новую проблему легко портируют и на него. Вон в ext4 баги десятилетиями никто не исправляет https://github.com/torvalds/linux/commit/b1489186cc8391e0c1e...
> Слишком много "если" и никаких гарантий, что на другом ядре и ОС
> этого не случится. Даже если это старое ядро, новую проблему легко
> портируют и на него. Вон в ext4 баги десятилетиями никто не
> исправляет https://github.com/torvalds/linux/commit/b1489186cc8391e0c1e...У сабжа баг тоже на поверку оказался далеко не вчерашний так то. А то что новую фичу запилили, и она помогла спровоцировать это в более легко воспроизводимом виде - вообще совсем другая история. На память о которой у ряда счастливчиков думающих что все ЗБС в ФС будут битые файлы. А в силу меньшей вероятности - они как раз и не заметят факап. Это еще прикольнее, подождать пока по бэкапам разлетится, старые бэкапы подтереть, и тут однажды вдруг - обана! Оказывается что файл битый - и такой уже пару лет, так что и все бэкапы с ним такие же. А то что пару лет он не требовался... ну... мало ли чего.
Сижу на ZFS с 2012 года и не потерял ни единого бита информации. А на btrfs постоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что btrfs - надежная ФС? :)
не трать время на срывателя покровов, он так и не понял, что ошибка выжившего распространяется на обе стороны и с упорством кра5ногла3ика продолжает хвалить свое болото.
Про ошибку выжившего иди Фейсбуку (миллионы серваков на Btrfs) рассказывай, а в будущем и Red Hat, когда на RHEL будет Btrfs по-умолчанию. Сейчас Btrfs по-умолчанию в Федоре. Ты в курсе, что это значит? Бгг.
>по-умолчанию в Федоре. Ты в курсе, что это значит?Что федорка снова стала полигоном для RHEL? Как и раньше
Вы не теряли, а я терял. Даже трижды.
Противоположнпая ситуауия: потерял целый раздел на бтрфс, с тех пор не пользуюсь, а на зфс все хорошо.
Хорошо что тебе повезло
Выбор мужчин в свитере: кора дуба и ext4. Хватит лить смузи в монитор.
Чем проще ФС тем надёжней, целостность данных должны обеспечивать аппаратные контроллеры, а то сидят болваны и трясутся чтобы файлы не пропадали, зато с чексуммами всё ок, хаха.
они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софт, только поправить его Вы не сможете.
Причем там почти наверняка linoops с mdraid. Т.е. без структурной целостности, с write hole и ресканом всего массива если неудачно выключили.По крайней мере для контроллеров areca это было доказано. Нет, разумеется, исходники этого линукса тебе никто не даст.
А ты думал, в сказку попал, и у изготовителей контроллеров какая-то своя, особая магия, а не сп-женый "6ешплатновзятьвзятьвзять" код линукса? Причем самый примитивный и дрянной из возможных, потому что внутри контроллера особо не развернешься.
зачем ты выключаешь?
жаль, что фряха перешла на кодовую базу от этих криво-лапковых> Изначально проблему попытались устранить в версии 2.2.1, но исправление оказалось неэффективно.
ну что это такое?:(((
> жаль, что фряха перешла на кодовую базу от этих криво-лапковыхДа, потому что в ней скорее всего ТОЖЕ есть эта проблема - но патч от open не подойдет, этот кусок кода даже в файле другом. Внешне - похож, так что скорее всего таки да.
Внезапно, этот кот - кого нада кот. Либо из самого сана пришел, либо жертва давней-давней переделки parallel zfs (гуглите, не обещаю что найдете)
> ну что это такое?
не угадали источник, со сложными тяжело воспроизводимыми проблемами это бывает.
Котиков?
Исходный баг присутствует и во фряхе тоже, не парьтесь.
Оно очень древнее. Народ подозревает, что аж с 2006 года ещё от санок, но подтвердить не может.
md уже научился на горячую диски менять? а дешёвые LSI - запросто.
> md уже научился на горячую диски менять? а дешёвые LSI - запросто.mdadm --replace
существует по-моему с 90х годов прошлого века. А с дешевыми lsi можно очень недешево влететь.
На горячую это когда не прикасаясь ни к какому софту вынимаешь диск из зеркала, вставляешь такой же новый и он сам инитится и встаёт в работу.
А ты его вставил вообще-то в надежде хоть что-то вытащить с еще не до конца но вот-вот сыплющегося второго. Успех гарантирован.Нет, спасибо, именно из-за этого в моих собственных системах никогда не будет udisksов и тому подобного вредного г-на, лезущего к железу без явной моей команды. (я бы и udev отправил следом, но это уже нереально сделать)
> они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софткоторый решает одну задачу но хорошо. А у вас комбайн сиськид это плохо а комбайн зоофс хорошо - это другое, там пингвинами не пахнет! ну кушайте не подавитесь.
> который решает одну задачу но хорошо.тоже нет.
> который решаетНет
> одну задачу
Тоже нет
> но хорошо
И снова нет. Я понимаю, конечно, что на локалхосте с LA 0.0 не повозишься особо с такими контроллерами, но в интернете-то хотя бы почитать или старших товарищей спросить не судьба?
>> они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софт
> который решает одну задачу но хорошо.Мне как-то виндочка драйверок обновила на таком. Заодно и фирмвару рефлешнуло, чего теряться?! А весь массив на этой чуде каааак дал дуба! Вечер вторника сразу перестал быть томным...
Невыдуманные истории, о которых невозможно молчать(с)А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :)
> Невыдуманные истории, о которых невозможно молчать(с)
> А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :)внезапно, на заре опеннета пингвинятки во всю топырили гузки что их md недоразумение быстрее (дешевых и помойных) адаптеков. Правда начинали исходить на гуано, когда их тыкали клювиками в виндовый рейд (который таки был быстрее и адаптеков и md - тогда не умевшего даже параллелить чтение с зеркал. Не уверен что уже научился, они ж еще маленькие, всего 25й годок)
> Невыдуманные истории, о которых невозможно молчать(с)Что есть то есть - #$%ля с сервантом на ровном месте, с выкапыванием по помойкам старой фирмвари и рефлешем фирмвари вниз полуправдами, чтобы вернуть как было, вместо легкого апгрейда - это шикарно.
Еще мне понравилось как интель на своих серваках делал дрова под конкретный SP - а если у вас не он ... упс ... вы обновили систему и райду - кабзда. При том если от накатки нового SP она гарантированная, то от вон тех KB - а вот попробуйте угадать, какой апдейт вам драйвер нагнет! Русская^W редмондская рулетка! В смысле райд то после вон того остается нормальный, только его драйвер более не работает, а на сайте интел мило так: "buy new server and press any key" - потому что поддержку вашей модели мы тут очень кстати дропнули месяц назад, так что ВОТ вам а не сервиспак! Все для удобства клиента! :)))
> А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :)
Да упаси меня от этих феккальев после btrfs'а. Я скорее поверю что это для меня bcachefs смогет. У него к тому предпосылки есть, иерархический стораж это кент прикольно придумал.
> Изначально проблему попытались устранить в версии 2.2.1, но исправление оказалось неэффективно.все, что нужно знать об опенсорсных авторах этого проекта:((( linux-way all the way^(((
Как будто у ваших авторов хот-фиксы к патчам к исправлениям каждый вторник исправлений эффективны.
Там даже хуже - вообще не поглядеть, чего в очередной раз нафиксили.
Ты не захочешь это увидеть.
После полистывания утекших исходников - ну, да видимо.
Не, там есть интересное, но в общем и целом у меня во-первых это жизни разобрать не хватит, во-вторых после потребуется бригада психиатров...
> Там даже хуже - вообще не поглядеть, чего в очередной раз нафиксили.Зато фороникс развлекается бенчами - и в очередном из убунта делает 11 на 20% в среднем. Хотя если бенчить файлухи, с пристрастием - там наверное и 200% можно получить. Если не 300%. Конечно не в пользу виндов.
Ну вот, взяли и оперативно исправили, а столько вони было.
0.6.2 -- это порядка 10 (десяти) лет назад.Поймали на Gentoo, потому что там любят крутить все ручки сразу -- это к вопросу "зачем нужна Gentoo, когда есть RHEL, Debian и болгеносы на любой вкус?"
Как быть с ответом на вопрос "сколько ещё осталось подобных неполных проверок?" (и не только в ZFS) -- не понятно.
Gentoo нужнен хотя бы чтобы не тащить весь крап, который понапихали в дистрибутивы симулянты бурной деятельности из RH и сказочники из Debian
а чтобы без конца пересобирать go
Сквозная(с) целостность(tm).
Сначала побьёт данные, потом запишет.
С зияющей целостностью.
С чем всех фанатиков и поздравляю.
Прекрасный пример того, что бывает когда гнутики пытаются скопировать что-то рабочее.
И оно "как-то" даже работает. Но не всегда и не у всех.
А если именно у тебя не работает, то УМВР и иди "пердолься с конфигами"(с)Так и со всем остальным. Ну вроде скопировали, но то тут косяк, то там косяк.
Ого, так скоро вторая новость про повреждение данных в ZFS
Не в ZFS, а в OpenZFS. Это очень важная разница.
Так а первый по факту мёртв.
Обе новости касаются одного и того же бага, так что не считается. Баг можно исправить, а вот архитектурную ущербность btfrs уже ничем не вылечить.
Может тут кто мне объяснит, зачем нужен zfs в проде? А то в прошлом треде было "у меня торрентокачалка на zfs, поэтому это продакшон!!!111"
За шкафом?Зачем система хранения данных с управлением томами защитой от битрота и вот этим вот всем для хрениния данных?
Ну хрен его знает. Дай подумаю. Ну может чтобы хранить данные и управлять этим всем ну там целостность тома вот это всё.
Блин. Подожди. Я понял. Чтобы хранить данные! Для этого нужна система хранения! Или нет? Я запутался.
> Зачем система хранения данных с управлением томами защитой от битрота и вот
> этим вот всем для хрениния данных?Не бывает в современных системах битврота.
Бывают куда более масштабные повреждения, и тут уже что ZFS, что чёрт лысый - всё равно идти за бэкапом.
Как еще бывают. Вот я на днях словил. samsung evo 870 выпуска 2021 года, как оказалось, имеет серьезные проблемы качества. В смарте неожиданно выплывают битые блоки, и это на практически неюзанном ссд. Хорошо zfs пожаловался при очередном скрубе, ну и подправил заодно. Но ссд менять все равно конечно. Вроде пишут что самсунг охотно меняет их по гарантии, без особой огласки.
Бывает. Не настолько хороши алгоритмы коррекции в дисках. Не говоря уже что там ошибка может много где залезть, в том числе в ОЗУ системы.Диск вполне себе может выдать неконкретный блок. И это случается даже на небольших объёмах.
А когда у вас петабайты данных, то вероятность словить такое 100%.
Ну и вообще чексуммы не только от этого защищают.
Между единичным бит ротом и смертью половины дисков в пуле - есть много промежуточных состояний.
> Не настолько хороши алгоритмы коррекции в дисках. Не говоря уже что там ошибка может много где залезть, в том числе в ОЗУ системы.
> Ну и вообще чексуммы не только от этого защищают.диски не с помойки, PCIe c FEC, кэши и ОЗУ с ECC - вот это защищает, а от зоофс с чексуммами пользы не больше чем от бесконтактного ушу, только нервы успокаивает.
Какие вы диски используете и какой у них заявленный BER?
> Какие вы диски используете и какой у них заявленный BER?странно что вас BER интересует а не UBER, стандарт допускает 1 некорректируемую ошибку на ~1.1 петабайт для SSD корпоративного класса, к слову для домашних дисков на которых вы храните свою критически важную порнуху UBER допускается в 10 раз хуже.
ECC не защищает 100%, а только минимизирует до терпимого.> а от зоофс с чексуммами пользы не больше чем от бесконтактного ушу, только нервы успокаивает.
Люди скрупулёзно считали математику и внедряли необходимые решения, а у вас пользы нет. Ну нет так нет.
Когда добавляли в диски ECC - да, люди скрупулёзно считали математику и внедряли необходимые решения.
А у вас оно только "минимизирует до терпимого".
Ну и ладно, кто ж вас заставляет-то. Продолжайте юзать монструозный комбайн сверху, в котором вот это вот обсуждаемое - далеко не последнее.
> Не бывает в современных системах битврота.тем не менее - дефективные диски и контроллеры - еще как бывают.
И лучше иметь возможность узнать об этом вовремя и выбросить без потерь, чем узнать когда чудо-ext4 заявит что журнальчик того-сего и неплохо бы тебе, васян, ручками полезть в консольку.
Мне вот буквально на днях казалось бы супернадежное ентер-прайсное сочетание хитачивской схд и вмвари так принесло пое6аться. Как тебе полсотенки (к счастью отвалилась только пара сторов а не все сразу) систем вывалившихся в у кого бизибокс, у кого просто рак, потомушта "нишмалгла я тут твою ext4, какие-то там orphan nodes, потрахайся-ка ты вручную мальчик? Вместо утренней рюмки портвейна,блжад.
А те у кого была zfs - после ресета поворчали и сами поднялись.
> А те у кого была zfs - после ресета поворчали и сами поднялись.Конечно поднялись, там кроме ZFS вообще что-то было, учитывая, как оно с памятью работает?
например там база заббикса была (далеко не оптимальная задачка для zfs). И никаких ручных действий не потребовала. Но поскольку убунту трагически сложно ухитриться целиком взгромоздить на zfs- ее системный диск был ext4. И его потребовалсь пнуть вручную чтобы хотя бы загрузиться дальше (rescue) - не смотря на чудо-журнал и прочие модные подпорки под идеей сталетней давности.
А в чем сложность?
> А в чем сложность?myisam в общем-то противопоказана жизнь на cow fs. Особенно такой как у жабикса, где бесконечные инсерты и такие же бесконечные удаления. Фрагментация действительно это подтверждает.
Но железо справляется, поэтому переделывать никто не будет.
Скорее уж целиком запихаю на zfs чтоб не как в прошлый раз.
А если использовать SLOG?
ничем особо не поможет. Там есть особенности, отключать которые опасно (никто не понимает как это работает а вот подтвержденные случаи потери баз - были) а если не отключать оно тормозит что с выделенным zil, что без.
zil это не writeback кэш, это double buffer.И отдельно - сбой slog device - это "unable to import pool" - 100% надежный способ пойти за бэкапом.
Происходит аккумуляция и агрегация до сброса на пул. Между интервалами commit данные могут многократно изменяться, но запишутся только самые последние изменения, что помогает заметно снизить темпы фрагментации. Преимуществ масса! Как вариант, можно установит commit=1,2... и sync=disabled - что поможет заметно улучшить агрегацию данных, с риском потери данных 1,2...секунд.
Продолжу мысль, если использовать SLOG, то можно задраться commit до вполне себе космических величин - что отлично поможет в борьбе с фрагментацией.
Трёхтерабайтная база заббиха живёт уже лет 10 на ext4, и ни разу не чихнула.
> Трёхтерабайтная база заббиха живёт уже лет 10 на ext4, и ни разу
> не чихнула.держи в курсе нам очень интересно (нет).
А вот что будет если на ходу выдернуть sata шлейфик? (примерный аналог того что случилось с SAN у нашего)
[рвёт на голове волосы]
Там нет SATA-шлейфика...
На самом деле - ничего не случится.
Выпадет накопитель с рейда.
Ну тогда все может быть гораздо интереснее. В эпоху когда рейды были не адской редкостью или атрибутом подвальных, а банально в каждом серваке - совершенно не было необычным в массовой эксплуатации за ночь получить пару алертов, утром поменять две сгоревшие платы и обнаружить что вторая оказалась чуточку не той ревизии и...вотЪ...А при отключении питания в DC как все интересно (нет, bbu не помогают)
При отключении питания в DC веселье в основном в том, что часть систем надо перезапускать в другом DC.
Кластеры разбираются сами, у них есть третья или пятая сторона, многосервиски с балансировщиками тоже, а вот менее критичные некластеризованные вещи да, может случаться и руками переносить.
В основном из-за того, что некластеризованные системы не любят сплитбрейнов, и перед переносом желательно удостовериться, что отказавший DC действительно лежит, а не связь с ним пропала временно. Если не удостовериться - да, можно и веселье с множественным доступом к LUN получить, тут уже никакая ZFS не спасёт.
Неужели так нравится позориться? Боже, мой Господь Бог...
Не нравится - не позорься.А суть в том, что ZFS для ФС - монструозна, и это далеко не последняя подобного рода проблема в ней.
Плюс то, как она вообще из палок на колене слеплена (её с системным кешем не просто так не удаётся интегрировать) - опять же не улыбает.
Прикладная мерфология фанатикам таковой не прилететь не могла - и в этот раз прилетела аж до визга.
> Не бывает в современных системах битвротаВас обманули.
Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять, в тех же секторах. При этом сами диски никаких ошибок не выдавали, просто чексуммы в zfs не сходились.
Через некоторое время до дисков «дошло», и они начали выдавать ошибки чтения (и были заменены по гарантии).
> Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно
> попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять,
> в тех же секторах. При этом сами диски никаких ошибок не выдавали, просто чексуммы в zfs не сходились.Ищите проблему в платформе.
> Ищите проблему в платформе.Гхм, в том же массиве ещё 11 точно таких дисков, с ними проблем нет. Сейчас глянул, аптайм дисков 4 года.
И с теми, что поставили на замену этим двум с бэдами, тоже проблем нет.
Поделитесь моделью дисков плиз, по крайней мере буду знать, с чем не связываться.
Хотя вряд ли я с этим конечно свяжусь просто по факту - скорее всего будет отсечено по другим критериям.
Сейчас стоит далеко не один массив с разными дисками. Есть место, где у флеша общий налёт 5 лет.
Есть место, где у оставшихся HDD уже десятка.
ST16000NM002G
Вообще дисков на 10+ у меня за сотню, есть и sata, и sas; по производителям — сигейт и hgst/wd.
Проблемы вылезли только на этих двух накопителях; но, конечно, количество накопителей недостаточное чтобы делать какие-то выводы о надёжности конкретных моделей.Всё, что я знаю — это то, что silent data corruption случается. Да, скорее всего, речь о банальном баге в прошивке, но от этого не легче.
Кстати, автор vitastor'а тоже долго не верил в необходимость чексумм, потом столкнулся с порчей данных на ST8000NM0055
Вообще у этих дисков так-то T10-PI есть. Так что либо кто-то что-то, либо просто используется что-то эдакое.
не уверен, что есть (но не проверял).
даже если и есть, t10 pi сам по себе ничего не делает, нужно переформатировать диски на нестандартный размер сектора + нужен софт, который умеет с этим работать.
Зачем софт? Выносные RAID-контроллеры вполне себе умеют. Те же перки с 9 начиная.
> Зачем софт? Выносные RAID-контроллеры вполне себе умеют. Те же перки с 9
> начиная.не пробовал, не скажу. в люблю случае, доверия к zfs у меня куда больше, чем к некоторому пропиетарному контроллеру (да ещё и заточенному под определённого производителя серверов).
и да, за счёт использования merkle tree у zfs чексуммы гарантируют консистентность фс даже если накопители врут, сомневаюсь, что perk предлагает что-то подобноену а то, что для этого функционала не требуется нестандартный формат — ещё один плюс zfs (да, с заменой по гарантии была долгая история, мы заменили эти накопители на то, что было под рукой, как бы не sata)
Вообще убедили, пожалуй попробую собрать dm-integrity там, где может прилететь с накопителя.
Но ради этого неадекватной сложности комбайн ZFS - это как 14 гвозди башенным краном забивать.
Ну вот сейчас часть ребят с TrueNAS'ом резко перестали верить в волшебность чексумм :D
> Ну вот сейчас часть ребят с TrueNAS'ом резко перестали верить в волшебность
> чексумм :Dу этих ребят все тихо - не представляю себе use pattern позволяющий на NAS напороться на этот баг. Там просто нет такого софта.
Там уже подтвердили, что напоролись, вроде.
Тем более что в режиме SAN почти наверняка для дискарда write hole во все поля.
А записать задискарденный блок и сразу попробовать его прочитать - это вообще норма жизни.
> А записать задискарденный блок и сразу попробовать его прочитать - это вообще
> норма жизни.так он прочитается. Проблема только при поиске пропущенных блоков, совершенно не понимаю зачем это SAN
В том-то и дело, что там как раз таки возможен рейс при котором он не прочитается.
Нет, не только при поиске. Вообще идентификация. Т.е. читнёт нули как раз.
там исправляли только и исключительно поиск нулей. И ничего больше.(причем все исправление - если нам надо проверить (а не прочитать) нули - дергаем flush и сидим тихо пока не сольется)
А так - да, в последнее время с сигейта ушли на hgst, сигейт достал падучестью.
Silent data corruption действительно случается, его и обсуждаем.Вообще сами по себе лишние чексуммы - безусловное добро. Зло - это монстр, которого ради него пытаются втюхать в нагрузку. Я вот в этом плане думаю, может просто через dm блочный слой чексумм присобачить...
(правда hgst wd теперь, но не суть)
Так-то LVM с dm-integrity вполне себе, и не нужно никаких ZFS'ов.
> Так-то LVM с dm-integrity вполне себе, и не нужно никаких ZFS'ов.Так то сделать эрзац btrfs/zfs можно и из той этажерки. Но вот когда захочется это еще и отменеджить и что-то переиграть - вот тут и вспоминаешь архитекта Криса Мэйсона, показавшего что это все может быть намного лучше чем вон тот истошный брейнфак. Который ты как-нибудь сам.
Другое дело, что экспириенс показывает, что это всё на практике не нужно, но вот на бэкапный сервер почему бы и нет, там как раз вероятность ошибки в долго живущих данных максимальна.
Вообще - честно - за 30 лет опыта все эти сказки про "потом вот нате развалилось" - вообще не умиляют. Потому что всё это скорее для красного словца, а ситуация - индикация проблем совершенно в другом месте.
> Вообще - честно - за 30 лет опыта все эти сказки про
> "потом вот нате развалилось" - вообще не умиляют.вообще-то совершенно типично для твоих любимых аппаратных рейдов.
Сперва начинаются дикие тормоза, и ты ищешь причину где ни попадя, пока не догадываешься посмотреть на чтение с дисков. А после пары-тройки ребутов - внезапно рейд спохватывается и сообщает тебе что один из дисков всьо (хорошо если один а не сразу два в raid5).
До этого момента причем не всегда даже можно угадать, какой именно - наружу тебе ничего не сообщают, просто тупят.
Дай угадаю, диски из ближайшего шопа? "RAID-optimized" диски как раз и отличаются тем, что мгновенно сообщают об uncorrectables, не пытаясь их мучительно читать. Причём разница в ценнике ныне может быть не заметной, отличие только в фирмвари.
> Дай угадаю, диски из ближайшего шопа?ты точно работаешь с рейдами, или все же - знания из реддита и википедии?
Так ведут себя штатные рейды в увешанном сертификатами и флажками лезвии IBM, например. Где IBM покупала эти диски - спрашивай у нее, они все в наклейках в три слоя, если хоть один оторвать, хрен тебе а не обслуживание.
(это еще именно IBM, впрочем, в леново такая же хрень только рейд другой и наклейки, само собой, другие. Диски, вполне вероятно, из той же помойки.)
> Причём разница в ценнике ныне может быть не заметной, отличие только
потому что в розницу их никто тебе не продаст. И даже не скажет что это.
> До этого момента причем не всегда даже можно угадать, какой именно -
> наружу тебе ничего не сообщают, просто тупят.В этом плане меня приятно удивляли рейды от hp — они просили поменять работающие диски. И несколько раз действительно угадывали (диск не меняли, а спустя какое-то время он уходил в ошибку).
Читал исследование, в котором для предсказания выхода из строя анализировались задержки дисков; не знаю, это да используется у hpe, или что-то другое
> В этом плане меня приятно удивляли рейды от hp — они просиливидимо, везло. Вообще-то они могут и на самом деле уметь что-то помимо стандартного dumb-smart Я-то полагал что перепрошивка там в основном s/seagate/hpe/g но возможно и не только (поскольку если ЭТИ вежливо попросят - им-то отдадут исходники и инструменты и еще благодарить будут).
идея контроля таймингов операций была как раз независимая от вендора и не требующая дополнительных атрибутов smart.
не удивлюсь, если она и с ssd сработает )
> идея контроля таймингов операций была как раз независимая от вендора и нену это странная идея - они у разных дисков могут быть разные и их надо мерять, где-то хранить, в общем не для прошивки занятие. Скорее всего что-то более простое у того хепе, тем более они могут себе позволить false alarms, потом у себя перепроверят, пятый слой наклеек налепят и можно еще кому-то поменять.
> ну это странная идея - они у разных дисков могут быть разные
> и их надо мерять, где-то хранить, в общем не для прошивки
> занятие.так важно не абсолютное значение, а изменение.
собирать статистику по нескольким ключевым таймингам на каждый используемый накопитель — не выглядит сложной задачей. поднимать аларм если вдруг какой-то процент обращений существенно выходит за пределы средних значений — тоже.сходу самое сложное на мой взгляд — это увязать всё это с глубиной очереди (отключать механизм при наличии очереди?).
Именно. А для статистики - маленький такой эластик с прометеусом и все это конечно же внутри прошивки.Неее, это так не работает. Там что-то совсем простое у них.
> Именно. А для статистики - маленький такой эластик с прометеусом и все
> это конечно же внутри прошивки.
> Неее, это так не работает. Там что-то совсем простое у них.да не нужно там никакого прометея, буквально десяток-другой байт в постоянном хранилище и может сотня байт в ОЗУ.
в общем, задача посильная для МК, что уж говорить о полноценных powerpc/arm в рейд-контроллерах.
> Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно
> попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять,да, можно модельку? Добавить в черный списочек.
Я за всю жизнь с такой х-ней ни разу не сталкивался, почему-то.
> да, можно модельку? Добавить в черный списочек.https://www.opennet.me/openforum/vsluhforumID3/132224.html#264
> Я за всю жизнь с такой х-ней ни разу не сталкивался, почему-то
точно подтверждённый случай вины диска у меня тоже один (ну два, если считать по накопителям).
а с порчей данных на накопителях сталкивался неоднократно, только на 100% вина накопителя была не доказана.
>> да, можно модельку? Добавить в черный списочек.
> https://www.opennet.me/openforum/vsluhforumID3/132224.html#264блин, то есть все exos?
Ну ооок...
Ну гелиевые Exos на самом деле редкостная дрянь.
Хуже были только VX.
Я с тобой говорить не собираюсь, ты профан и на этом сайте все это знают. СХД - это не ФС и никакого отношения не имеет. Зачем ты лезешь в диалог, если не разбираешься?? Белый шум какой-то.
Сорян, реально бесят такие люди, в каждой бочке затычка. Ну не разбираешься - ну помолчи. Нет, надо сказать какую-то ересь. Зачем?
> СХД - это не ФС и никакого отношенияОт оно как. Оказывается для хранения данных никаких ФС ненужно, и к хранению данных Файловые Системы никакого отношения не имеют.
Аноним, ты сегодня на коне!ZFS, кстати, это не только лишь ФС.
ну volume management в linoopsе у нее своеобразный. Я не проверял свежие версии, но то что я прочитал по поводу неработы zpool -e меня слегка расстроило. А когда я увидел КАК они это полезли чинить - мне что-то и вовсе расхотелось дальше копать.resize2fs тем временем - never fails.
Вообще да, к СХД имеет отдалённое отношение. И ZFS местами используют для этих целей не как ФС, потому что это нечто не только ФС
Это же зависит от вида прода. Для некоторого прода, например, нужны только сырые обычные диски
> Это же зависит от вида прода. Для некоторого прода, например, нужны только
> сырые обычные дискикакой у тебя фуфуфу немодный прод.
У правильного прода только block storage, только S3 !
А все остальное надо выбросить как нимодна, нималадежна и ни атвичаит современным тенденциям!
Бгг."So your best bet is if you have a known good source copy or hash from one, to compare your stuff against that. Anything else is going to be a heuristic with false positives and negatives."
Сквозная(c) целостность(tm) с хешами(r) внезапно потребовала ещё этих вкусных хешей.
Причём баг жил аж с 2013 года... Сколько фанатиков за это время приобрели никак не замеченные нули в файлах - ну, можно прикинуть. Впрочем, там рядовая практика была "ой, чёт пул слетел, надо переставлять", поэтоу есть мысль, что хранились на этом в лучшем случае торренты, поэтому особо никто и не замечал.
> Причём баг жил аж с 2013 года... Сколько фанатиков за это время
> приобрели никак не замеченные нули в файлах - ну, можно прикинуть.Э... ноль?
Часто у тебя возникает идея скопировать только что скопированный файл (причем именно копию, а не еще раз оригинал) ?Ну и еще надо было иметь очень оптимизированную систему, чтобы успеть это сделать до момента, когда уже будет поздно и он банально и неинтересно скопируется.
И очень интересный софт, умеющий в поиск holes. И это до недавнего времени был ни разу не cp.
> Впрочем, там рядовая практика была "ой, чёт пул слетел, надо переставлять",
Зачем ты транслируешь fud? Рядовая практика там - пи3данулось - да и х-й с ним. Вот только что после недели переговоров с хостером заменил совсем уже развалившийся диск. Ничего не пострадало, кроме моих нервов (он как-то плохо сдох, подвесив заодно и оставшийся рабочий, диски в недосерверах такое любят, нас...ть на шину так что вся ata встает колом)
Что забавно - это уже третий в той коробке (где их физически всего два) идущий нах..й за два года. Ну и ладушки, +терабайт свободного места (таких которые там изначально стояли, больше не делают, и очень хорошо что не)
> поэтоу есть мысль, что хранились на этом в лучшем случае торренты,
> поэтому особо никто и не замечал.торренты имеют собственный контроль целостности, поэтому еще как заметили бы. Но у тех кто там такое хранит - ничего не ломалось. Вот у каждодневых пересобирателей go - бываит. Им за эту ненужную деятельность - большое человеческое спасибо, отлично помогли найти сложный в обнаружении баг. Xyета Хрюндберг правда недовольна, но ей не до того - вчера жырные м-ки на хороших зарплатах не долетели из Мюнхена в Дубай на конференцию по глобальному потеплению. Их бизнес-джет примерз ж0пой к полосе.
Там речь не о копировании любого только что скопированного файла.
Там речь о попытке чтения из бывшей write hole после записи в таковую.
Ну я ATA не использую, только SAS, там всё попроще.
> Там речь не о копировании любого только что скопированного файла.
> Там речь о попытке чтения из бывшей write hole после записи в таковую.ДО записи.
Попробуй это воспроизвести в реальной жизни. Не пересобирая игого.
sas дохнет ничуть не хуже sata, всем бэкплейном сразу, не надо мне сказок про суперуникальные ентер-прайс решения, я на них не одну крысу съел.
Судя по количеству визга в треде в issues - воспроизвелось на отличненько.
> Судя по количеству визга в треде в issuesвоспроизвелось у трех человек помимо пересобирателей игогошечки, причем они постарались воспроизвести, внезапно (и это хорошо, что такие вообще еще остались).
И даже у пересобирателей через раз, понадобился скрипт чтобы воспроизводимость была хотя бы на уровне, позволяющем проверить баг.
Не ДО записи.
После записи и ДО сброса на диск.
Круто. Лучшая файловая система стала ещё лучше.
task txg_sync blocked for more than 120 seconds ]:}
> task txg_sync blocked for more than 120 seconds ]:}Что же они там такого накодили.
Во фре и солярке такого не наблюдается.
> Во фре и солярке такого не наблюдается.нет автообнаружения заблокировавшихся ядерных тредов, вот и не наблюдается.
Я в такое вляпывался на пресловутой 11.1
Воспроизводимость в конкретно моей конфигурации - 100%, мертвое повисание системы на make world, вероятнее всего из-за нехватки памяти при попытке обработать нехватку памяти. (как у них обычно)К сожалению, пока я пытался донести эту информацию до тех кто мог бы что-то поправить, из той конторы уволился и ноут отобрали. А там и ZoF стала немодно.
Попробуйте отключить abd scatter и arc compression - чем чорт не шутит, может это именно тот баг.
Хз, сегодня поймал от rsync локально на pool/ФС.
На pool/zvol с ext4 внутри через virtio льет нормально с максимальной для источника скоростью (пул на nvram, источник hdd)
Багу уже несколько лет https://github.com/openzfs/zfs/issues/9130