The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Код Bcachefs принят в основной состав ядра Linux 6.7, opennews (??), 31-Окт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


325. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 02-Ноя-23, 04:04 
ext4 с пофайловым сжатием и снапшотами была бы хороша (и чтобы и то, и то было не хуже, чем на оффтопике). e2compr был да сплыл, blksnap/dattobd/elastio-snap мутные и на замену VSS не тянут. Странно NTFS хвалить, но чёрт возьми, там эти фичи есть и ими удобно пользоваться.
Ответить | Правка | Наверх | Cообщить модератору

418. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 03-Ноя-23, 14:33 
> ext4 с пофайловым сжатием и снапшотами была бы хороша

У нее видите ли структуры для этого - не очень заточены. Для снапшотов не через джеппу надо CoW уметь, а это изначально как in-place делано. Да еще дурное наследие EXTов, так что вот вам лимит на число инодов. Это выжимка по максимуму легаси дизайна, попытка сделать летающее авто прямо из того что есть, не имея возможности привинтить Mr. Fusion. Ну оно и если работает - то уж как получится.

Ответить | Правка | Наверх | Cообщить модератору

433. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +1 +/–
Сообщение от Аноним (317), 03-Ноя-23, 17:17 
> Для снапшотов не через джеппу надо CoW уметь

Для снапшотов-как-способа-версионирования, где нужна хорошая работа с большим числом снапшотов. А для снапшотов-как-средства-для-бэкапов можно без CoW, который к тому же не бесплатно обходится. btrfs не смог в дефрагментацию со снапшотами, в таком смысле: "Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.".

Ответить | Правка | Наверх | Cообщить модератору

477. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 05-Ноя-23, 21:16 
> Для снапшотов-как-способа-версионирования, где нужна хорошая работа с большим числом
> снапшотов. А для снапшотов-как-средства-для-бэкапов можно без CoW,

У лично меня промежуточный сценарий. Я делаю снапшоты перед любым большим потенцильно ломающим изменением. Чтобы в случае откатиться. С другой стороны снапшоты - НЕ бэкапы и не заменяют бэкап на 100%. Зато быстрые и эффективные (а если это не так то зачем оно такое).

> который к тому же не бесплатно обходится. btrfs не смог в дефрагментацию со снапшотами,

Тем не менее, можно откатить эффект этого unshare блоков дедупалками. Это не идеально но продвинутым штукам - продвинутые причуды.

> в таком смысле: "Defragmentation does not preserve extent sharing, e.g. files created
> by cp --reflink or existing on multiple snapshots. Due to that
> the data space consumption may increase.".

Ну да. Однако как increase, так дедупалкой и decrease обратно. Если показать дедупалке всю иерархию конечно. Ext4 страшно далек от таких проблем - он вообще shared блоки не умеет. Как впрочем и сжатие, cow, чексумы, вот это все. Не говоря уже про человеческий менеджмент места и девайсов. Если что-то такое попытаться LVM и проч с сравнимыми возможностями - получится вообще кошмар.

Ответить | Правка | Наверх | Cообщить модератору

479. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 05-Ноя-23, 23:00 
> Тем не менее, можно откатить эффект этого unshare блоков дедупалками

Но если вовсю пользоваться версионированием, то тогда unshare выжрет всё место и перед дедупом надо будет удалить снапшоты во избежание.
> С другой стороны снапшоты - НЕ бэкапы

Конечно, достаточно того, с ними меньше проблем с консистентностью бэкапа. И раз для бэкапа нужен только один временный снапшот, то больших наворотов не требуется. Самый большой требуемый наворот - чтобы пользователь мог не думать о том, куда будет писаться diff ("the shadow copy storage area can be on the same volume" - мелкософт).
> Ext4 страшно далек от таких проблем

Да, это всё не имеет отношения к "платности" CoW'а, неудачно сформулировал. Платить ведь приходится:
- большим write amplification (WAF) на SSD
- большей фрагментацией
- производительностью
> получится вообще кошмар

У близости к земле бывают свои плюсы (хоть они и касаются не снапшпотов, а других фич, имеющихся в btrfs/zfs) - некоторые держат MergerFS + SnapRAID - получается недо-RAID5/6, не теряющий данные на живых дисках после смерти массива (из-за отсутствия striping'а) и не разваливающийся (из-за объединения не на блочном уровне; файлы всегда целиком лежат на одном диске).

Ответить | Правка | Наверх | Cообщить модератору

480. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 06-Ноя-23, 01:02 
> и перед дедупом

* перед дефрагментацией, конечно.

Ответить | Правка | Наверх | Cообщить модератору

493. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 08-Ноя-23, 19:33 
> Но если вовсю пользоваться версионированием, то тогда unshare выжрет всё место и
> перед дедупом надо будет удалить снапшоты во избежание.

Ну, у меня для версионирования проектов GIT есть, там еще коменты, мерж, "мультиплеер", и проч. А спамить себя пачками мало изменяющихся снапшотов на уровне глобального менеджмента систем - оно надо?

Но если надо, у btrfs при сильно большом числе снапшотов скорость работы с метаданными IIRC может просесть. Кент же если не ошибаюсь догнался до миллиарда, чтоли, снапшотов. Возможно это самый заснапшоченый капитан звездного крейсера с машиной времени. Не то чтобы мне
это надо, но технически может быть названо преимуществом дизайна сабжа. Лично меня больше интересует заявляемая "компактность метаданных" и "скорость", имхо. А возможно и хитроджепый кеш с учетом избыточности, до кучи несколько продвинутых хранилок забацать - почему бы и нет, раз уж оно так умеет? Не основной сценарий для меня но на правах приятного бонуса - вполне.

>> С другой стороны снапшоты - НЕ бэкапы
> Конечно, достаточно того, с ними меньше проблем с консистентностью бэкапа.

С другой стороны, 1 бэд под shared экстентом может сильно испортить настроение. Ведь не прочтется то вся пачка. Конечно если избыточность была это хорошо, но возможны и иные варианты. Скажем dd в блочные устройства, ошибка менеджмента снапшотов, пых питальника унесший все диски, системный сбой RAM/CPU/... вынесший метаданные ФС, или еще какой грубый факап который снапшотом не откатывается.

> И раз для бэкапа нужен только один временный снапшот, то больших наворотов не
> требуется.

Снапшоты удобны с точки зрения бэкапирования что они не будут меняться под бэкапалкой. Приветы, видимо, VSS, только тот - капец тормоз и ресурсожор. А в этих дизайнах снапшоты по сути халява. Однако понимание консистентности состояния файлов "in flight" это все же весьма отдельный топик.

Кстати в btrfs можно в ряде случаев и рефлинками это обыграть. Да и в сабже, вероятно, тоже. Я так скажем виртуалки зацеплял: делаю рефлинк диска прямо c запущеной VM, и цепляю рефлинка. Внутрях тоже btrfs обычно. Это как бы неправильно ("некорректный шатдаун"), но cow похрен, там лишь чуть более старое состояние будет. И кстати cow-на-cow таки тоже не рекомендуется. Но я c этими гипердвигателями возился столько что мне таки можно, если осторожно. Ибо я очень хорошо понимаю какой у меня размер дельт, что я собираюсь сделать, и вообще.

> Самый большой требуемый наворот - чтобы пользователь мог не думать
> о том, куда будет писаться diff ("the shadow copy storage area
> can be on the same volume" - мелкософт).

Я терпеть не могу их shadow copy, дико тормозное и контринтуитивное нечто. Юзеры не понимают как это работает, технари обычно не оценивают тупняки и жор места в контринтуитивном виде, и кому оно в таком виде надо я ХЗ.

Однако у лично меня - снапшоты в btrfs идут "на 1 уровень выше /" и его при нормальной работе системы таки не видно. Но при желании поменеджить это просто новое измерение, в котором живет некий ансамбль миров. Можно выбрать в который из них хочется попасть. Технически делается монтированием "full view" в любую точку иерархии. Но вот тут я понимаю как это работает. Саму структуру с subvolumes вот так - придумали убунтуи. Нормально придумали как по мне.

>> Ext4 страшно далек от таких проблем
> Да, это всё не имеет отношения к "платности" CoW'а, неудачно сформулировал.

Ext4 вообще нифига не умеет по сути и потомок намного более архаичных дизайнов. Его некорректно сравнивать с cow. Записи деструктивны (in place), полный журнал тормозной как черти что или если на это забить то структуры ФС конечно консистентны будут но вот файл из наполовину новой головы и старого хвоста - сомнительная радость. А без журнала данных это вообще никак не обыгрывается же.

> Платить ведь приходится:
> - большим write amplification (WAF) на SSD

Я помониторил статистику, сделал commit time побольше (200 секунд), врубил SSD + spread, да и пришел к выводу что если системный SSD за 5 лет протерся на аж 3%, не выглядит большой проблемой. Конечно, если бы это была нагруженная БД это другой разговор. Но я не DBA, мне пофиг, а для DB придумали NOCOW.

> - большей фрагментацией

1) SSD пофиг.
2) У btrfs дефрагер есть. Не идеальный но все же. ZFSники... ну, это их проблемы. Сабж - waiting for -rc1, тогда понятнее будет.
3) С другой стороны cow может писать выноски с полной скоростью куда там удобно.

В целом - ну да, чуть медленнее. Но не критично. И в сумме для меня оно того стоило учитывая новые возможности. А на одноплатниках где DUP парирует редкие единичные бэды это вообще EPIC WIN. Один с EXT4 у клиента рассыпался и было совсем не круто: бэд libc6 накрыл, девайс резко и без предупреждения стал тыквой. Возможность такой тыквы - хреновое свойство, DUP улучшает теорвер в другую сторону. Системные образа у меня мелкие - ополовинивание места не парит.

> - производительностью
>> получится вообще кошмар

В моих сценариях - не получается никаких кошмаров. Так на глаз от ext4 вообще малореально отличить в большинстве случаев. Кстати btrfs'ники с своим bg_tree новомодным - сделали ext4 и xfs по скорости монтирования, я получил приятный бонус к скорости загрузки систем в ряде случаев. Кент вообще сразу на перфоманс ориентировался, premature optimizations сыграли с ним дурную шутку, типа FTBFS на ряде архитектур, терок с майнтайнерами, W^X viol и проч.

> У близости к земле бывают свои плюсы (хоть они и касаются не
> снапшпотов, а других фич, имеющихся в btrfs/zfs) - некоторые держат MergerFS
> + SnapRAID - получается недо-RAID5/6, не теряющий данные на живых дисках
> после смерти массива (из-за отсутствия striping'а) и не разваливающийся (из-за объединения
> не на блочном уровне; файлы всегда целиком лежат на одном диске).

Для меня 1 из ключевых плюсов btrfs это простой понятный и логичный менеджмент файлухи, минимум возни с ней, self heal/малообслуживаемость, ненужность fsck и проч. Чего и Кенту желаю. И снапшоты для меня это такой способ сделать менеджмент bare metal удобным, в стиле виртуалок почти.

Заниматься всякой многоэтажной камасутрой с супер-решениями хз зачем, черти-чьими технологиями хз где и трехэтажными наслоениями костылей - не мое, мне удобно когда все-в-одном в майнлайне, я доверяю этим господам, ряду команд из, а не кому попало. Бонусом я так то data recovery немного балуюсь. Btrfs я уже понимаю достаточно для того чтобы в пиковой ситуации иметь шансы, особенно с их офлайн читалкой прямо в штатных тулсах, да и btrfs'ники - полезные и эффективные господа оказались, когда я баги встретил. Интересно этот опыт с Кентом сравнить будет.

... кстати Кент время зря не терял и пока окно приема открыто, он только что забомбил большой "довесок", который догоняет bcachefs в кернеле до master. Как-то так выглядят сверхновые^W переход на интеграцию с майнлайном, видимо, комит c9d01179e185f72b20af7e37aa4308f4c7ca7eeb

Ответить | Правка | К родителю #479 | Наверх | Cообщить модератору

495. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 08-Ноя-23, 23:12 
> Ext4 ... полный журнал тормозной как черти что
> придумали NOCOW

От новых файловых систем всякого хотят. Кому-то без data journal норм, а с потерей новых фич в nodatacow - не норм. Ладно сжатие отваливается, но ведь и data checksumming тоже. Осталось добавить в btrfs шифрование и тоже его отрубить для nodatacow.

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

Шифрования в btrfs нет. Придётся наслаивать. RAID5/6 в btrfs "как бы нет". Снова наслаивать.

Cryptsetup предлагает добавить контрольные суммы для всего (добавить dm-integrity уровнем ниже dm-crypt). Тут уже задумаешься, нужно ли сверху наслаивать именно btrfs, а не что попроще, если одна из её фич так легко замещается*, а красиво, шоб всё в одном как в ZFS, всё равно не получается.

И глядя на ZFS начинаешь сильнее ценить гибкость, потому что слишком многое там делается через "Если к вам пришли гости, а у вас ничего нет, пошлите человека в погреб, пусть принесёт фунт масла, два фунта ветчины, дюжину яиц, фунт икры, красной или чёрной, и приготовьте лёгкие закуски"... то есть "пошлите человека в погреб, пусть принесёт стопку HDD, чтобы собрать ещё один массив и таким образом отменить дедупликацию, сделать дефрагментацию или ещё какую мелочь". Уж что-что, а невероятную гибкость MergerFS+SnapRAID даёт**.

Ещё журнал ext4 и контрольные суммы dm-integrity выносятся на отдельное устройство побыстрее. Вроде костыли, но зато какие - можно пальцем показывать на SPECIAL vdev в ZFS.

Чем менее популярна ФС, тем меньше инструментов для восстановления данных, тоже такое.

* но будет сложнее искать, какой файл задел битый сектор
** это звучало бы убедительнее, если бы я сам ими пользовался

Ответить | Правка | Наверх | Cообщить модератору

501. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 10-Ноя-23, 15:50 
> От новых файловых систем всякого хотят. Кому-то без data journal норм,

И без прочих чексум, хренли. EXT4 вообще плевать хотел на участь юзеровских данных и ничкому нишиша не гарантирует. Даже с RAIDами блин, там как я понимаю вообще нет плана если диск в RAID отдаст левак в секторе. Это - то как работает этажерка костылей и наслоений. Просто побьет данные втихаря, вы даже и не узнаете. До тех пор пока оно не потребуется конечно, тогда узнаете, но к тому моменту сколько там времени пройдет, может у вас и бэкапы все уже убитые с этим давно, все ж файлы в каждом бэкапе проверять жрут ли их реально программы - сами понимаете.

Меня больше всего смущает что вон те хотельщики с такими ФС смеют что-то предъявлять на тему целостности данных. Им бы определиться чтоли с хотелками. Они что, хотят глюкать на откровенно сыпящемся оборудовании, пусть данные бьет, но совсем в ноль не сыпется, дескать? Или чего? Вот это - и правда странное желание ряда "экспертов" как по мне. Как по мне таких "экспертов" лучше не слушать, данные целее будут. А у них самое ценное что есть это сэйвы в гамезе какой поди да торенты которые перекачать можно.

> а с потерей новых фич в nodatacow - не норм.
> Ладно сжатие отваливается, но ведь и data checksumming тоже. Осталось добавить в btrfs
> шифрование и тоже его отрубить для nodatacow.

Ну так на EXT4 вообще чексум нету. И ничо - эксперты жрут. А nodatacow это такой режим для БД и прочих "fs-like" сценариев типа CoW дисков виртуалок, желавших делать большую часть того что ФС делала самостоятельно. Включая и журнал, и что там еще. Это вот такой себе режим "как в EXT4". Если кто хотел фичесет EXT4 и чтобы работало так как оно, он ЭТО и получает. На что жалобы? И почему EXT4 это же самое не предъявляется, интересно? :)

>> хз где и трехэтажными наслоениями костылей - не мое, мне удобно
> Шифрования в btrfs нет. Придётся наслаивать.

Во первых оно нужно не везде и не всегда. Во вторых вот именно его как раз не очень сложно наслоить. Но так между делом fscrypt для btrfs по-моему даже уже где-то летает в виде патчей.

> RAID5/6 в btrfs "как бы нет". Снова наслаивать.

RAID56 это такая штука что стоит дважды подумать - а хочется ли это вообще. Особенно RAID5 и/или в "классическом" виде с write hole, когда потом еще и понять трудно - а что вообще побилось. Да и менеджмент ЭТОГО с наслоениями - булшит полный, "храните 100500 идентичных девайсов на складе". Очень удобно и практично. А btrfs может почти любую схему на "произвольном числе девайсов" делать. Там аллокация простраства куда более разумно делается чем блочный трешак с выравниванием на эн чушек равного размера и никак иначе. Это дает свои проблемы, зато менеджмент ЭТОГО - вообще совсем иная история. И попробовав однажды вбивать координаты в бортовой компьютер гипердрайва уже совсем не хочется назад на механические тяги. Вообще совсем никак. Это совсем иной уровень технологий и управления системами.

> Cryptsetup предлагает добавить контрольные суммы для всего (добавить dm-integrity уровнем
> ниже dm-crypt). Тут уже задумаешься, нужно ли сверху наслаивать именно btrfs,

Ну как бы btrfs при несовпадении чексум в RAID1 или даже DUP (мало ли, бэдсектор вылез) - просто утащит данные из 2 копии. Восстановив в фоне порушеный кус. Наружу софту это вообще не видно. А у вас на такой случай какой хитрый план? Особенно с крипто, где отклонения от идеала запросто ведут к массовым потерям данных. Вон та механика как себя поведет если разные зеркала разные данные отдали? А то реальные сторажи зачастую вместо кончины начинают просто отдавать какой-то левак. С избыточностью и чексумами понятно что, можно понять кто нам г отгрузил. И дальше пофиксить, а если это часто - то и заменить девайс. А вон там этот сценарий - как?

> а не что попроще, если одна из её фич так легко замещается*, а красиво, шоб
> всё в одном как в ZFS, всё равно не получается.

Мне ZFS не надо: его нет в майнлайне, да и с его дизайном он только для энтерпрайзных файлопомоек и имеет смысл. Меня имхо больше всего интересует как раз то что озвучил Кент: стыковка general purpose и продвинутых технологий. И всякие нестандартные сценарии. А вот файлопомойки мне если и интересны - то только до кучи.

> HDD, чтобы собрать ещё один массив и таким образом отменить дедупликацию,
> сделать дефрагментацию или ещё какую мелочь". Уж что-что, а невероятную гибкость
> MergerFS+SnapRAID даёт**.

С вон теми оговорками - видите ли я привык к тому что btrfs не только "находит" это, но еще и SELF HEAL делает! Так что пара бэдов с трухой или нечитаемых - вообще не проблема. Если избыточность была, конечно, потому что чудес на которые фаны EXT4 уповают - не бывает. Если избыточности нет, то и предсказуемого flawless recovery - тоже. А вон там уже можно потрепыхаться и оно таки стоит определенной возни, если одноплатники не дохнут от 1 бэда, ноут не разваливается внезапно в хлам, и вообще.

> Ещё журнал ext4 и контрольные суммы dm-integrity выносятся на отдельное
> устройство побыстрее.

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

> Вроде костыли, но зато какие - можно пальцем показывать на SPECIAL vdev в ZFS.

Кому надо - тот пусть и показывает. Это буду не я, ибо я уже понял где я такой менеджмент файлух видал благодаря Крису Мйэсону показавшему что можно и сильно получше чем это все. Кент, вроде, азы создания звездолетов - вот - усвоил. Это и делает его дизайн интересным мне.

> Чем менее популярна ФС, тем меньше инструментов для восстановления данных, тоже такое.

У btrfs прямо в штатных тулсах офлайн вычитывалка с альтернативным парсером. И возможностью опробовать разные точки входа в иерархию, cow же не сносит все и сразу, так что можно здорово потрепыхаться. Круче любых r-studio, тирамис и проч. А еще открытое, бесплатное, и с адекватными девами воооон там которые даже при серьезном настрое - расскажут и помогут. Конечно если это не совсем чайник, у них нет ресурсов азы давать. Но если я пришел и точно знаю что мне надо - я это получаю. И довольно быстро, как показали эксперименты.

>  * но будет сложнее искать, какой файл задел битый сектор
> ** это звучало бы убедительнее, если бы я сам ими пользовался

Ну вот с такими оговорками... я вот жру пирожки которые рекламирую. И поводом для рекламы является тот факт что мне это нравится :). *

* Сабж, конечно, я юзать еще чисто технически в эксплуатационном виде не могу, там мне нравится дизайн и мышление его архитекта, а также общая упертость оного, когда он гнет свою линию несмотря на все траблы. Будущее должно принадлежать таким людям, тогда в нем будет прикольно жить. А когда апстрим рефлинки 15 лет делает из CoW дизайна, и ни 1 бага на майнлайн с левым модулем не вкатишь - зачем мне такой дизайн, право? Я часть тех процессов - по своим причинам. Мне это надо.

Ответить | Правка | Наверх | Cообщить модератору

506. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 11-Ноя-23, 04:50 
> И без прочих чексум, хренли. EXT4 вообще плевать хотел на участь юзеровских
> данных и ничкому нишиша не гарантирует.

А с этим живут по таким причинам:
- Без ECC-оперативки данные всё равно могут побиться в памяти. Data checksumming заделает дырочку в надёжности хранения, но у пользователей не-ECC-оперативки останется дырища рядом.
- Диски жёсткие и твердотельные имеют ECC. Его хватает, чтобы сказать "тут bad block", а не молча вернуть прочитанный из нужного места мусор. Использовать софтовый data checksumming - значит не доверять end-to-end protection внутри диска (если он есть) или заменять его, расширять его на остальные звенья (SATA-контроллер). То есть это мера против потенциального отсутствия ECC в прочих видах памяти (где лежит/исполняется прошивка, где различные буферы/кэши), против ошибок и недоработок в прошивке, вызывающих в том числе phantom writes, misdirected reads/writes. Впрочем, если SSD перестарался с попытками коррекции и вместо ошибки выдал ложноположительный результат - это и недоработка в прошивке, и молчаливое возвращение прочитанного мусора...

Тут кто первым надел халат, тот и доктор.

15 лет назад одни надели халат и похоронили RAID5. Из-за одного загадочного числа в спеках жёстких дисков - URE/UBER (RAID6 дали отсрочку). Не сбылся их прогноз о дисках, которые сложно прочитать целиком без единой ошибки (12+ ТБ, URE=10^-14), халат отняли.

Другие халат не снимают, потому что у них ext4/XFS или винда без ReFS или макось. И работает. И тихое повреждение данных кажется слишком мифологизированным. Мол, data checksumming необходим там, где обитают хранилки с 520/528 байтами на сектор, но не везде.

Ты халат надел, а базу данных и виртуалки допустил положить в nodatacow. Приравнял к торрентам и сохранениям в играх в аспекте контрольных сумм. Пожертвовать контрольными-суммами-для-данных ради скорости? Вот так остальные файловые системы и работают.

> Даже с RAIDами блин, там как я понимаю вообще
> нет плана если диск в RAID отдаст левак в секторе.

Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности при чтении (а не только при ручном запуске проверки).

Как я понимаю, эта же проблема будет в btrfs+nodatacow и её не будет* с dm-integrity, о котором писал ниже.

* защита от misdirected reads/writes должна требовать дополнительной настройки.

> Меня больше всего смущает что вон те хотельщики с такими ФС смеют
> что-то предъявлять на тему целостности данных.
> Им бы определиться чтоли с хотелками.

Почему бы и не хотеть, у всех свои приоритеты. Некоторые вообще считают, что люди вокруг не используют ZFS, потому что им не важны их данные. Тоже отказывают в иной расстановке приоритетов и отмахнутся от твоих слов про "не general purpose", достанут очередной свежий баг в btrfs и станут размахивать им: https://bugzilla.redhat.com/show_bug.cgi?id=2169947.

Чем холоднее данные, тем больше вариантов открывается, вплоть до par2.

> И почему EXT4 это же самое не предъявляется, интересно? :)

Так речь о хотелках по новым ФС, как некоторые фичи накостыливаются-наслаивается к старым ФС - понятно. Дарю убийственный аргумент: "нечего тут на опеннете рассуждать, иди и сделай свою правильную ФС, делом займись".

> Ну как бы btrfs при несовпадении чексум в RAID1 или даже DUP
> (мало ли, бэдсектор вылез) - просто утащит данные из 2 копии.
> Восстановив в фоне порушеный кус. Наружу софту это вообще не видно.
> А у вас на такой случай какой хитрый план?

Если он рутинно вылез, то диск сам о нём скажет, чексумму от ошибки не посчитаешь. Если прочитался мусор без  ошибок, то загадочное тихое повреждение данных не стоит бэдсектором называть.
> md: read-error will instead cause md to attempt a recovery by overwriting the bad block. i.e. it will find the correct data from elsewhere, write it over the block that failed, and then try to read it back again.
> dm-integrity: dm-integrity target can be used to detect silent data corruption on the disk or in the I/O path.

По-хорошему, все сетапы надо проверить через внедрение ошибок. Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?), zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup.

PS: в предпредыдущем комменте отступы сломал, там везде "цитата - ответ":

> [Если что-то такое попытаться LVM и проч с сравнимыми возможностями -] получится вообще кошмар

У близости к земле бывают свои плюсы [- там, где посконные "LVM и проч", там и MergerFS со SnapRAID].

Ответить | Правка | Наверх | Cообщить модератору

513. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (-), 12-Ноя-23, 23:04 
> А с этим живут по таким причинам:

Забыли еще пару: отсутствующие знания, а то и склонность заменять знания измышлизмами. Впрочем хуже от этого в основном носителю такой точки зрения, покуда они ее не распостраняют.

> - Без ECC-оперативки данные всё равно могут побиться в памяти.

На практике btrfs при таком обычно орет "csum error" в логи и если юзерь не совсем баклан... из того что на виду, отловился глючный проц и пару плашек оперативки как раз. Неплохой валидатор работы оборудования получился.

А то что EXT4 и прочие NTFS молчат в тряпочку - так это до поры. Когда метаданные совсем в труху разносит - юзеры таки познакомятся с датареком. Я несколько таких NTFSов выковыривал, после этого конечно оперативу меняли, но там уже труха на диске. Самое ценное конечно достать обычно удается, с той или иной степенью урона, но такой том только под реформат потом: он глючный что капец и может в любой момент обвалиться опять.

> - Диски жёсткие и твердотельные имеют ECC. Его хватает, чтобы сказать "тут
> bad block", а не молча вернуть прочитанный из нужного места мусор.

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

Во первых что там сделает немеряный фирмвароблоб - целиком на его усмотрение. Реакция фирмвар на подобные вещи весьма разнообразна.
Во вторых FEC может с некоей (небольшой, но не нулевой) вероятностью посчитать рандомную труху за что-то валилдное. Это редко, но с ростом плотности устройств, числа секторов и погоней за емкостью и ценой за счет общей хлипкости...

Поэтому на практике я видал как девайсы выгружают из секторов явный левак, не удосужившись сообщить IO error. И у тех додиков на такой случай плана нет. У многих райдов, кстати, тоже. Btrfs то при наличии чексум - вопит csum failed, БЕРЕТ БЛОК С ДРУГОЙ КОПИИ (точно зная что хочет и какой там чексум), чинит битую копию, заодно и кривой сектор ремапнуть получится. Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать, спасибо если не вбив девайс в failsafe mode, после чего юзер уж точно к датареку пойдет. И один сектор, который фирмвари ремапнуть раз плюнуть, может эскалировать в убер-проблему, фатальную и дорогую. Потому что сами вы уже оттуда ничего не вытащите скорее всего.

> Использовать софтовый data checksumming - значит не доверять end-to-end protection внутри
> диска (если он есть) или заменять его, расширять его на остальные
> звенья (SATA-контроллер).

Это как раз отличная идея, чисто с точки зрения теорвера. Если вероятность лажи чексумы ФС 1/N и девайса 1/M то вероятность что они ОБЕ одновременно лажанут - уже 1/(N*M) что куда как прикольнее. А девайсы выгружающие треш в секторах без репортов IO Error я лично видел. Btrfs то на это вопит csum failed и чинит, чего б ему не.

У меня даже есть пара особо сыпучих флех - посмотреть, проиграю я когда теорверу с схемой DUP на заведомо хреновом носителе или нет :). Реально - на сыпучей флехе становится можно таскать файлы ценой ополовинивания емкости, таки не мрет по простому.

> ошибок и недоработок в прошивке, вызывающих в том числе phantom writes,
> misdirected reads/writes.

Де факто это end to end проверка работы железа. И это очень хорошо. Дада, и 1 глючный шнурок тоже под внимание попал за "csum failed". А какой-нибудь ext4 тихо схарчил бы такие пакости.

> Впрочем, если SSD перестарался с попытками коррекции и вместо
> ошибки выдал ложноположительный результат - это и недоработка в прошивке,

Если вместо того чтобы умничать на форумах сходить качнуть лекции CS где расписаны типовые алгоритмы и их свойства, можно узнать что чудес не бывает и есть некая вероятность что алгоритм примет труху за чистую монету. И чексум может сойтись на левых данных. Конкретика конечно зависит от деталей, типа ширины чексумы. FEC вообще не чексум, он в этом качестве "до кучи" подрабатывает и имеет довольно компромиссные свойства, но не тратить же места еще и на чексумы, убавив емкость на лэйбе девайса?! Отдел маркетинга вас не поймет.

> и молчаливое возвращение прочитанного мусора...

Я пару раз даже на HDD такое видел, а для флешастых девайсов это "довольно типовой" faulure mode я б сказал. И статистика конечно же набралась потому что я знакомым btrfs нарекламил. Ну мы вместе и узнали о свойствах оборудования. И о чем не пишет отдел маркетинга.

> сбылся их прогноз о дисках, которые сложно прочитать целиком без единой
> ошибки (12+ ТБ, URE=10^-14), халат отняли.

На самом деле для небольших инсталяхах IMHO RAID5 можно и попытаться. Но только понимая ограничения этого всего. Вообще делать большие или пролвинутые сетапы совсем не понимая тематику - чревато.

> Другие халат не снимают, потому что у них ext4/XFS или винда без
> ReFS или макось. И работает. И тихое повреждение данных кажется слишком
> мифологизированным.

Я паре таких мифологов потом с их NTFSа выколупывал добро. Когда винды в бсод при маунте нтфс начинают улетать - так то да, даже жирафу заметно что гамно какое-то :). В этом месте линуксоид под боком срубает свой EPIC WIN. Хотя-бы за счет альтернативного парсера который в синий скрин ну вот не уходит.

> Мол, data checksumming необходим там, где обитают хранилки с 520/528
> байтами на сектор, но не везде.

Я btrfs в довольно большом числе довольно разных сетапов юзаю, от SD и eMMC до нескольких многодисковых штук (RAID1 в основном) и ну вот не считаю чексумы чем-то лишним.

> Ты халат надел, а базу данных и виртуалки допустил положить в nodatacow.

Если я это сделал - у меня был какой-то запасной план на этот случай. Я не одиваю халат чтобы своей некомпетентностью пациентов гробить.

> Приравнял к торрентам и сохранениям в играх в аспекте контрольных сумм.
> Пожертвовать контрольными-суммами-для-данных ради скорости? Вот так остальные файловые
> системы и работают.

Ну как бы если кому плевать на свои данные я так то не против, но когда они при этом начинают высовываться и что-то про (не)надежность ФС лечить - это не находит моего понимания.

> Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности
> при чтении (а не только при ручном запуске проверки).

Ну а вот BTRFS заметив сбой чексумы берет из второй копии и чинит. Выглядит как-то так:


[82374.200674] BTRFS info (device sdg): scrub: started on devid 1
[82471.511063] BTRFS error (device sdg): fixed up error at logical 3180593152 on dev /dev/sdg physical 5336465408
[82491.759994] BTRFS error (device sdg): fixed up error at logical 2634088448 on dev /dev/sdg physical 5863702528

Это катитт и с DUP на 1 девайсе, и с RAID1 на разных. Не обязательно scrub пинать, обычное чтение тоже котируется. Это я для иллюстрации как сие работает на заведомо-сыпучей флехе scrub пнул чтобы увидеть сбой чексум и его парирование за обозримое время.

> Как я понимаю, эта же проблема будет в btrfs+nodatacow и её не
> будет* с dm-integrity, о котором писал ниже.

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

> * защита от misdirected reads/writes должна требовать дополнительной настройки.

К сожалению во всем этом мусоре - нормальный менеджмент не завезли. В btrfs DUP на однодевайсном конфиге 1 командой делается. Прозрачно. На ходу. Без дестроя. Теперь донавесьте 2 копии на 1 девайсе с авто-фиксом факапов вашим способом. Ну или почем мой ноут или те выводки одноплатников не могут попытаться парировать единичный бэд, например? У меня вот могут - и это оказалось полезным улучшением свойств файлух как по мне.

> твоих слов про "не general purpose", достанут очередной свежий баг в
> btrfs и станут размахивать им: https://bugzilla.redhat.com/show_bug.cgi?id=2169947.

Надо же какая новость, в софте баги бывают. Проблема в том что багов бывает в самом разном софте. И если кто утверждает что btrfs в этом уникален - значит он целенаправленно втирает очки. А так да, рассылки блочников и файлушников и проч лучше на ночь не читать, спокойно спать не сможете.

Но говоря за себя - в моих конфигах это просто работает. Какие-то проблемы я огребал только с -rc ядрами, заодно узнав что brtfs'ники очень крутые, компетентные и оперативные ребята которые горой за качество своей вундервафли. Сообща оттрекали и загасили все что мешало мне жить. Опенсорс - это вот так. А желаюшие быть консумерами и получить ынтырпрайз грейд экспериенс именно его и получат. И пусть потом не плакают, а хотя-бы и занося чемодан денег или выписывая баги в какое там спортлото.

> Чем холоднее данные, тем больше вариантов открывается, вплоть до par2.

Оно как бы да. Но у всяких штук типа снапшотов есть плюсы в том что они создаются шустро, и поводом к их откату обычно является факап на совсем ином уровне. А бэкапы никто не отменял. Просто это достаточно долгая операция с своей канителью и невкусным временем рекавери.

> Так речь о хотелках по новым ФС, как некоторые фичи накостыливаются-наслаивается к
> старым ФС - понятно. Дарю убийственный аргумент: "нечего тут на опеннете
> рассуждать, иди и сделай свою правильную ФС, делом займись".

А таки разработчики ФС зачастую открыты к разумным пожеланиям. Особенно если они не сильно сложно натягиваются на эннфй дизайн. А иногла даже и сложно. Ну вон в zfs 10 лет поотмазывались но все же смогли сову, на глобус, тьфу, рефлинки то-есть на "типа cow". Позор ситуации в том что XFS который изначально не cow и то раньше это смог. Думаю прозрачно намекает почему Кент копипастил с btrfs дизайн, а не с того нечто. Оно ж даже экстенты полноценные не умеет и затыкает тормоз-дизайн гигазами оперативы.

>> А у вас на такой случай какой хитрый план?
> Если он рутинно вылез, то диск сам о нём скажет,

Вооооон выше пример фикса на именно подленькой сыпучей флехе, которая как раз и не утруждает себя сообщением IO error, вместо этого выгружая труху. А вот btrfs подляну видит и даже чинит. И вполне себе может жить с этим - если избыточность есть.

> чексумму от ошибки не посчитаешь. Если прочитался мусор без  ошибок, то загадочное
> тихое повреждение данных не стоит бэдсектором называть.

Btrfs в случае IO error сразу идет за другой копией и чинит из нее. И какая разница по csum failed это инициировано или по io error. На результат не влияет.

> По-хорошему, все сетапы надо проверить через внедрение ошибок.

У меня есть даже небольшая коллекция особо мерзеньких девайсов. В основном благодаря btrfs и его чексумам. Вот заодно и посмотрю как штука Кента отнесется к этому самому. Мне ж не нужна сферическая файлуха для идеального вакуума.

> Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?),
> zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup.

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

А те долбаные этажерки - пусть их похи всякие используют, вместе с другими экспертами. И очень круто что господа типа Кента понимают где такому менеджменту систем вообще и ФС в частности на самом деле место. На помойке! И скучать по всему этому брейнфаку мало кто будет, имхо. А интеграция ФС и девайсов дает нефиговые новые возможности, которое вон то либо не может, либо реализует так что лучше б и не позорилось. Типа какихнить снапшотов в LVM. Нахрен мне такие снапшоты после того как я btrfs попробовал. И у Кента они по идее должны быть не хуже. Но это еще предстоит проверить.

Ответить | Правка | Наверх | Cообщить модератору

514. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 13-Ноя-23, 11:52 
> На практике btrfs при таком обычно орет "csum error" в логи и
> если юзерь не совсем баклан... из того что на виду, отловился
> глючный проц и пару плашек оперативки как раз. Неплохой валидатор работы
> оборудования получился.

Эмм, в оперативную память кладут и другие вещи, помимо данных для btrfs scrub. И они побьются заодно. Только контрольной суммы у них не будет. Но перед записью на диск появится, подсчитанная от уже побитых данных. Случай с глючной оперативкой (которую можно выявить и иначе) достаточно очевиден, а халат нужен в разговоре про космически-лучевые soft error'ы.

> Это может себе вообразить только тот кто никогда не интересовался как это
> работает и видимо не имеет особого опыта эксплуатации компьютерных систем.

Поведай, зачем тогда изобрели RAID-массивы. В них (без доп. data checksumming'а) не было бы смысла, если бы диск обычно умирал "тихо". Хотя и так ясно, что изобретатели не интересовались, как это работает и не имели особого опыта.

На этом держатся все системы без контрольных сумм для данных (без T10-PI, ZFS, btrfs, ReFS, dm-integrity што там ещё).

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

> Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать

Но что сможет сделать btrfs без избыточности? ext4-без-массива-под-ней здесь всё-таки как соломенное чучело для спора.

> Если вместо того чтобы умничать на форумах сходить качнуть лекции CS

Можно и патенты Hynix с его miscorrection metric'ами и miscorrection threshold'ами. Перестараться - это, наверное, некорректное упрощение, но всё-таки у SSD есть возможности следить за своим здоровьем, свалиться в fail-safe пораньше.

> Я пару раз даже на HDD такое видел

Вот это интересно. А про SSD - в ресурсном тесте 3dnews вроде три экземпляра умирали подобным образом и это разочаровывает, исход с тихим повреждением не должен становиться нормой.

> На самом деле для небольших инсталяхах IMHO RAID5 можно и попытаться. Но только понимая ограничения этого всего.

Мой посыл был только на тему халатов.

В 2007 появилась нашумевшая статья* о том, что RAID5 через два года придёт конец из-за URE=10^-14. Остальные риски для автора не имели значения. Не важно, умрёт ли диск во время ребилда, когда даже обычный исправный диск нельзя прочитать без нескольких неисправимых ошибок (бэд-блоков). И эти мысли укоренились. Говаривали даже, что RAID0 надёжнее RAID5 - математически доказано - всё равно во время ребилда** ошибки похоронят массив на ~10+ ТБ, а дисков в RAID0 меньше.

Получилось интересное помешательство. Часть людей поверила в рассказ про RAID5 и URE, не задумываясь о том, что реальный URE гораздо ниже. Не задумываясь, что каждый первый scrub якобы должен исправлять по ошибке на дисках типа Toshiba N300 16TB. Что без избыточности (RAID/DUP) такие диски должны быть не бесполезны, а даже опасны. Что их SMART должен плодоносить ошибками.

* https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
** В остальное время бэд-блоки спят. Автор не учёл, что по его теории во время обычной работы должно происходить постоянное исправление бэдов, невозможное в RAID0.

> Ну как бы если кому плевать на свои данные я так то
> не против, но когда они при этом начинают высовываться и что-то
> про (не)надежность ФС лечить - это не находит моего понимания.

Говоришь как тот адепт ZFS. Ветка почти началась с коммента про скорость (второй в ветке, не мой). Дальше говорил о цене фич, о пофайловом сжатии и снапшотах, которые бы добавлялись без компромиссов ("Парето-оптимально"), о шифровании, о чексуммах-для-данных-на-уровне-ФС как приятном бонусе.

> > Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности
> > при чтении (а не только при ручном запуске проверки).
> Ну а вот BTRFS заметив сбой чексумы...

Ну так не спорю. Только подтверждаю, что не видел такого.

> > Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?),
> > zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup.
> И пусть себе есть. Где-то там.

Это полезные этажерки, не обижай их. Это эмуляторы особо мерзеньких девайсов.

Ответить | Правка | Наверх | Cообщить модератору

516. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (516), 13-Ноя-23, 18:21 
> Эмм, в оперативную память кладут и другие вещи, помимо данных для btrfs
> scrub. И они побьются заодно.

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

> Только контрольной суммы у них не будет. Но перед записью на диск появится,
> подсчитанная от уже побитых данных.

Теоретические измышлизмы это прекрасно. А вон то - смотрение как это на практике работало. Это было надежнее чем выслушивать опеннетных экспертов, и я по факту видел - вон то. О чем и спел.

> Случай с глючной оперативкой (которую можно выявить и иначе) достаточно
> очевиден, а халат нужен в разговоре про космически-лучевые soft error'ы.

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

> Поведай, зачем тогда изобрели RAID-массивы. В них (без доп. data checksumming'а) не
> было бы смысла, если бы диск обычно умирал "тихо".

В них допущение что диск мрет катастрофично и сразу. По мере роста плотности и скоростей, усугубленных желанием юзерей все и сразу и за копейки, это стало все менее похоже на правду. И таки в обычном RAID на этот случай плана нет. Без чексум будет разрушение данных.

...это дает дизайнам с чексумами преимущество. Если я вижу кейсы где это срабатывает и чинит, своими глазами, о чем вы тут вещаете?

> Хотя и так ясно, что изобретатели не интересовались, как это работает и не
> имели особого опыта.

Когда все начиналось плотности были другие и соотношения - тоже. О том что со временем реалии могут несколько измениться - эксперты, видимо, не в курсе.

> На этом держатся все системы без контрольных сумм для данных (без T10-PI,
> ZFS, btrfs, ReFS, dm-integrity што там ещё).

Они так то довольно специфично держатся. Редко но метко караптя данные - и поскольку чексум нет, как вы это узнаете то если оно изредка? А, ну вот когда что-то осыпется - тогда и :). Только опять же - а откуда вы узнаете кто вас подвел, DMA переписавший что-то в раме или хард вернувший труху? Опосля - уже не видно.

А если вот конкретно тут на чтении с конкретного девайса чексум не сошелся - я таки знаю что девайс вернул труху. И могу посмотреть был ли формально IO error заодно. Что я и практикую.

> Слова я выбирал, категоричности избегал, дальше мысль раскрыл, исключения описал.

А я тут описываю по большей части то что видел лично. Своими глазами. А еще есть следствие из законов Мерфи. "Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили". В случае добра без чексумм это просто квинтэссенция инженерной мудрости.

А что до категоричности - если я смотрю на явление своими глазами и мне тут кто-то лечит что не, это не проблема - я несколько не ОК с этим. Если теория не описывает картинку которую я вижу, это хреновая теория, которая должна быть списана в утиль. Тут нет места для компромисса. Теория или стыкуется с практикой, или нет. Для нестыковки хватит 1 конкретного примера. Который я и привел. Вполне себе девайс выдающий левак без IO error. Мой тестовый кролик теперь, ибо весьма подленькая штука отловленная случайно.

>> Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать
> Но что сможет сделать btrfs без избыточности?

Он так то метаданные по дефолту DUP раскладывает на 1-дисковых конфигах. Вот как раз из соображений выживаемости и датарекавери. Для данных это ессно надо мануально врубать потому что ополовинит место на девайсе и скорость записи. Но в ряде конфиг с этим можно жить. А сделать аналог этой фичи как-то еще - ну не то что совсем нельзя, но такой гимор и side effects что этим никто заниматься не будет. А тут 1 команду вбить и готово.

> ext4-без-массива-под-ней здесь всё-таки как соломенное чучело для спора.

А с массивом под ней - соломенное чучело переезжает в менеджмент всей этой пакости. Кода все сложно, хреново, не гибко, плохо поддается динамической реконфигурации. А узнать что именно /dev/sdf выгрузил труху даже не изволив в IO error - да удачи.

А чтоб еще это прозрачно парировать в фоне без моего участия...  хм, у меня на основе этой технологии выводки одноплатников, допустим, есть. А вы хоть раз в жизни такой сетап собирали вообще, чтобы рассказать мне как это на практике работать будет?

> Можно и патенты Hynix с его miscorrection metric'ами и miscorrection threshold'ами.

Лекции CS полезнее - там алгоритмы как они есть, без приукрас. С честной оценкой свойств. А производителей флеша - более одного, технологий тоже.

Вон то наблюдение чисто статистическое, я есть в некоторых местах где юзеры с упомянутой траблой иногда рисуются. И у меня есть несколько сыпучек ведущих себя вот именно так. Btrfs пополнил мою коллекцию странной фигни.

> Перестараться - это, наверное, некорректное упрощение, но всё-таки у SSD есть возможности
> следить за своим здоровьем, свалиться в fail-safe пораньше.

На практике как я вижу все это работает не очень хорошо и являет собой полную лотерею. А разложить bcache на ssd это вообще известный способ закончить с разнесенной в хлам файлухой. Но поскольку это дает нефиговую оптимизацию IO - колятся, пищат, но кактус грызут. Глядя на это Кент и интегрировал сабжа с этим на уровне ФС. Так оно имхо сможет менее горбато на факапы SSD реагировать. С чексумами, избыточностью и явным знанием что и где это имеет шансы работать гораздо лучше.

> три экземпляра умирали подобным образом и это разочаровывает, исход с тихим
> повреждением не должен становиться нормой.

Я лично на такие приколы натыкался. Этого достаточно чтобы считать failure mode имеющим место быть. Раскидать btrfs там и тут очень способствовало обнаружению подобных сюрпризов. А как вы это без чексум по простому отловите, интересно?

> В 2007 появилась нашумевшая статья* о том, что RAID5 через два года
> придёт конец из-за URE=10^-14. Остальные риски для автора не имели значения.

Ну как бы некий пойнт автор имел, но как обычно в таких штуках страшилки бывают несколько преувеличены. Однако не учитывать подобные проблемы как и шанс что за время ребилда помрет +1 девайс тоже глупо. Есть некие соотношения, риски, варианты что делать с этим. Если RAID это такой вариант в духе снапшотов, что если что и из бэкапа восстановимся, но намного лучше если прокатит без этого - то и RAID5 некая опция.

> Получилось интересное помешательство.

В вопросах storage вообще нездоровое количество маркетингового булшита и предрассудковю Поэтому я прежде всего верю своим глазам. Отсюда же и довольно бескомпромиссная реакция на "csum failed без IO Error". Видел такое -> бывает -> маркетинг и теории идут в пень, без компромиссов и дискуссий. И я уже не скажу что не знал что так бывает. Знал и должен учитывать эти данные в принятии решений.

> Часть людей поверила в рассказ про RAID5 и URE,
> не задумываясь о том, что реальный URE гораздо ниже.

Ну это тоже раз на раз не приходится. Воооооон та сыпучка с которой пример - куда злее. Если ее записать, кинуть недельку поваляться и проч - scrub найдет с дюжину рандомных осыпонов. И это факт. Который я могу повертеть в руках. И я не могу сказать что так не бывает, получив столь вопиющий факт в руки. Другое дело что и тут можно проблему классифицировать. Это вероятнее на флешовых устройствах, чем дешевле и low end тем вероятнее такой расклад. Но вообще FEC может быть пробит. Вероятность этого далеко не ноль. На самом деле я просто подружился с FEC до уровня "имлементера" по своим причинам и проинформировал себя о реальных свойствах алго - а не измышлизмах.

> типа Toshiba N300 16TB. Что без избыточности (RAID/DUP) такие диски должны
> быть не бесполезны, а даже опасны. Что их SMART должен плодоносить ошибками.

А таки btrfs по дефолту вернули DUP на SSD. Догадаетесь почему? Повышает выживаемость файлух у юзерей. По крайней мере не дает метаданные урыть - а данные, ну, да, это плохо, но масштаб урона при сносе метаданных куда как.

> теории во время обычной работы должно происходить постоянное исправление бэдов, невозможное
> в RAID0.

Сам стораж вообще не может починить "UNC" - а как? Но если файлуха забьет на эту копию, возьмет из другой, а эту деаллоцирует или перезапишет, проблемный сектор таки более не нужен и получит запись в него - и вот тут уже фирмварь сможет посмтреть читается ли это, и если нет то сделать этому ремап. Без потерь данных.

>> про (не)надежность ФС лечить - это не находит моего понимания.
> Говоришь как тот адепт ZFS. Ветка почти началась с коммента про скорость
> (второй в ветке, не мой). Дальше говорил о цене фич,

Ну как бы адепты ZFS были первыми кто это осознал. Просто их звездолет на паровой тяге и гипердрайв с их стимпанк технологиями очень уж сыкотно выглядит. Но даже так они поняли ряд тех вещей которые понял я.

> о пофайловом сжатии и снапшотах, которые бы добавлялись без
> компромиссов ("Парето-оптимально"), о шифровании, о чексуммах-для-данных-
> на-уровне-ФС как приятном бонусе.

Можно рассматривать гипердрайв как приятный бонус. Но если я при перспективе расплющиться о твердь смог проскочить через планету и рематеризоваться на другой стороне орбиты одним куском, вбив в последнюю секунду параметры в компьютер, а лох на хвосте так не умел, окей, а вот это уже его проблемы! Главное что это - не у меня.

> Ну так не спорю. Только подтверждаю, что не видел такого.

Вероятность этого заисит от числа инстансов btrfs, активности их эксплуатации, внимания к системным логам, характера сторажей и много чего еще. Смею заверить что я не уникум, видал немало юзерей с таким добром, чаще всего SSD так прикалывается.

> Это полезные этажерки, не обижай их. Это эмуляторы особо мерзеньких девайсов.

У меня есть и просто "особо мерзенькие девайсы" :).

И кстати если мы про это... 


* [new tag]                   v6.7-rc1   -> v6.7-rc1

Ну, кто хочет поработать тестовым пилотом? Крейсер в первом приближении свинчен и ждет в доке. Настало время плюхнуться в кресло капитана хотя-бы манекену - и посмотреть что эта штука может. Удачных приключений в гиперпространстве, и добро пожаловать в будущее. Которое создается сегодня :)
Ответить | Правка | К родителю #514 | Наверх | Cообщить модератору

520. "Код Bcachefs принят в основной состав ядра Linux 6.7"  +/–
Сообщение от Аноним (317), 14-Ноя-23, 02:52 
> Теоретические измышлизмы это прекрасно. А вон то - смотрение как это на
> практике работало. Это было надежнее чем выслушивать опеннетных экспертов, и я
> по факту видел - вон то. О чем и спел.

Верну контекст: после отсеивания изначально проблемной памяти можно жить и примерно одинаково страдать от единичных космических лучей что с btrfs, что без btrfs. Тут теорвер btrfs не поможет, единичное повреждение в non-ECC RAM скорее всего заденет не его данные.

> В конечном итоге btrfs там где я его выидел выловил вот проц,
> пару планок рамы, шнурок и даже чипсет. А какие у вас
> на все эти случаи планы были кроме теоретических разглагольствований я не
> понял.

Но они очевидны, дождаться первых проблем и: память - memtest, SATA-кабель - проверка 0xC7 CRC Error Count в SMART'е, процессор и чипсет - страдать, менять всё с запасом. Ну и организационный момент, конечно - пассивное ожидание kernel panic более фатально, ожидание настроенного уведомления о плохом SMART'е и проблемном scrub'е менее фатально. Если хочется ещё раз провозгласить, что это менее удобно, то я опережу: "это менее удобно".

> В них допущение что диск мрет катастрофично и сразу. По мере роста
> плотности и скоростей, усугубленных желанием юзерей все и сразу и за
> копейки, это стало все менее похоже на правду.

Всё-таки там допущение, что диск сообщит об ошибке, не обязательно своей смертью. Не такое уж плохое допущение, ибо скоростей на HDD и так нет, надёжность требуется и юзверям, унификация корпоративных и домашних HDD есть, рост плотности в 10^9 раз за историю HDD остальным аспектам надёжности заметным образом не повредил, поэтому пусть и обнаружению ошибок не повредит. С SSD хуже, да, но там как минимум Samsung'у надо оправдывать ожидания (на 3dnews тихим повреждением отличились Silicon Motion и Phison) и - пожелание в /dev/null - тихое повреждение на SSD не должно становиться нормой.

> Если я вижу кейсы где это срабатывает и чинит, своими глазами, о чем вы тут вещаете?

О здравом смысле. При высокой частоте тихих ошибок классические RAID-массивы стали бы бесполезными, даже до домохозяек доносили бы мысль через анекдот "печатаю 1200 ударов в минуту, но такая ерунда получается" и они бы смутно помнили, что QNAP почему-то нельзя покупать*.

А раз классические RAID-массивы не бесполезны, то ECC обычно хватает и лишний пафос не нужен, чтобы сказать "да, такие делают, в них есть не-ко-то-рый смысл, но я рекомендовать не могу". Оговорки о пользе контрольных сумм были ("из нужного места" => исключение misdirected read/writes, "вызывающих в том числе misdirected read/writes"), а всё хочется видеть, будто я говорю об их бесполезности.

И у нас разговор в одном русле идёт:
- Есть жизнь и без btrfs/ZFS
- Да разве это жизнь!?
- Живём как-то.
- Да вы не знаете, что такое жизнь!
- Но мы живы, вот это вот device mapper, тут par2, а это...
- Вы существуете.

* Why does QNAP NAS not use the Btrfs file system? https://www.qnap.com/solution/qnap-ext4/en/

> А что до категоричности - если я смотрю...

Да-да, то есть нет. Лучше так:
- Вы таки утверждаете, что ECC на диске всегда хватает для обнаружения ошибки?
- Не всегда, да и проблема не ограничивается miscorrection'ами.

> > Ну так не спорю. Только подтверждаю, что не видел такого.
> Вероятность этого заисит от числа инстансов btrfs...

Аргхм, не видел другого - реализаций RAID, жертвующих скоростью ради чтения всех зеркал/чётности и сверки при каждом обращении к данным. Вот FUSE на основе Рида-Соломона видел, а такое не видел.

Ответить | Правка | К родителю #516 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру