Для любой помойки сойдет.

@komar даже если я наркоман и буду им эмулировать raid? допустим, на одном диске из зеркала файл читается без ошибок, но кривой. легко ли будет реплицировать назад копию с верной чексуммой? или придётся ебаться как в https://github.com/gluster/glusterfs/issues/491

че за bitrot? битики флипаются время от времени? какие конкретно задачи ты хочешь решить?

@enterprize решится если ты поднимешь кластер из минимум двух нод, файл всегда отдастся верный или не отдастся (если ты забекапишь где-нибудь топовый хеш отдельно)

@voker57 > какие конкретно задачи ты хочешь решить? если коротко — съебать с zfs > че за bitrot? битики флипаются время от времени? флипаются, пусть и редко — zfs мне, может, раз в год рапортует о восстановлении каких-то копеек данных с кривой чексуммы из второй копии, то на одном сервере, то на другом. если б не был таким параноиком, может, свалил бы на ext4+mdraid.

@enterprize рекомендую lfs, гоняю его на файлопомойке, жесткие дохнут каждый год, ввожу команды наугад по мануалу, данные живы

@voker57 *lvm

@voker57 попробуй наугад вводить команды в mdadm

@komar боюсь выйдет беда

@voker57 М?

@voker57 чот не вижу в lvm/device-mapper чексумм данных

@enterprize raid5 тебе даст чексуммы.

@enterprize dm_integrity

@voker57 о, бля, проглядел, спасибо

@komar не помню, чтобы кто-то в пятом рейде сверял чексуммы при чтении. а даже если бы сверял: какой блок восстанавливать будешь, если не сходится?

@enterprize На хуй, по-твоему, там вообще чексуммы, если они никогда не сверяются, и по ним невозможно ничего восстановить?

@komar mdadm это какая-то ручная ебля с софтверными рейдами, а у меня десять винтов с помойки, закинул в пул, расширил lv и свободен

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

@enterprize | хуй | пизда | 0610899fa9a3a4300e375ce582762273 | как же, блять, теперь определить, хуй был или пизда

@komar поздравляю, ты нихуя не понимаешь, как работает raid5

@enterprize А как он, по-твоему, работает? Как raid1, в котором нельзя читать третий диск, чтобы жизнь медом не казалась?

@voker57 Твой lvm сам решает, какого уровня у него рейд сегодня?

@komar нет, но диски сам выбирает.

@voker57 С полки сам достает, что ли?

@komar Из vg.

@voker57 Я не понимаю по-петушиному.

@komar а как, по-твоему, в raid5 на 4 диска доступного места на три диска получается?

@komar я говорю lvm -- вот у меня есть десять дисков разного калибра, на них уже пять разного рода разделов, мне нужен новый раздел на 2тб в два миррора. Он набирает по дискам мне под него кусков. mdadm так умеет?

@enterprize Один диск приносится в жертву Сатане, очевидно.

@voker57 Ах. Нет, конечно. Но земля тебе пухом с таким использованием дисков.

@komar пруф

@komar ебатьдебил.жпг (хуй xor пизда xor джиругда) = X, на 4 диска идут | хуй | пизда | джигурда | X | если хуй не читается совсем, он восстанавливается из (пизда xor джигурда xor X) а если вместо хуя прочитался комар, то мы никогда не узнаем, из-за какой переменной (комар xor пизда xor джигурда = X) не сходится а то, что ты описал, не raid5 вообще и вообще хуй найдёшь такое

@enterprize Я описал ситуацию, когда страшный bit rot уже случился, и надо из | хуй | пизда | 0610899fa9a3a4300e375ce582762273 | как-то восстанавливать исходные данные.

@komar > raid5 тебе даст чексуммы > Я описал ситуацию, когда страшный bit rot уже случился заебись слился.

@voker57 Да я даже не знаю, что сказать. У тебя получается дорогой массив, где в случае поломки «малонужные» данные проебываются, а «нужные» хранятся расточительно. А в случае глобального пиздеца ты даже наскрести вручную данных не сможешь. Продай свои харды бедным детям, а на вырученные деньги сделай уже себе пятый (шестой) рейд — и купайся в дисковом пространстве.

@enterprize По-моему ты совсем тупой. Я тебе пытаюсь на элементарном примере показать всю примитивность восстановления данных в случае, когда ты якобы «не можешь понять, из-за какого блока нихуя не сходится».

@komar малонужных у меня на постоянной основе вообще нет, в чем расточительность не понял. Какого уровня нужен глобальный пиздец и чем он помешает photorec тоже. Детей беднее меня тут нет.

@komar а я заебался уже объяснять, что твой элементарный пример — не то, как работает ссаный raid5, который должен «дать чексуммы», и вообще иррелевантен нахуй

@voker57 Расточительность в том, что ты дорогой массив используешь как бюджетную конфигурацию из двух жестких дисков.

@enterprize Прощу прощения. Я не знаю, что raid5 работает не на чексуммах, а на ебле твоей мамки в жопу.

@komar Я использую бюджетную конфигурацию из десяти дисков как бюджетную конфигурацию из десяти дисков. Если ты про то что там есть временно неиспользуемое место, то оно там для того чтобы не бежать в магаз за диском когда нужно будет моар.

@komar ты всегда такой аутист? придумал себе какую-то охуительную схему, назвал её raid5 и думаешь, что если использовать настоящий raid5, то всё у всех будет как в твоих влажных фантазиях

@voker57 Ты используешь raid 1/0 со смешной тулзой для конфигурации.

@ceyt после zfs internals испугать метаданными сбоку меня уже сложно

@komar использую, он мне и нужен. Тулза отличная.

@ceyt метаданные там же где и данные, что куда испарится?

@komar у md/dm RAID5 нет блочных чексумм. он не защищает от битрота. raid5 в btrfs и zfs - защищает.

@voker57 потестил. кажется, на этом даже можно жить. конечно, по инерции после zfs хотелось бы fletcher4, деревьев Меркеля, поменьше срать в klog и не говорить каждый раз в `integritysetup open`, какие там чексуммы должны быть, но после kernel oops-ов в zio/arc/spl три раза в год этого более чем достаточно.

@enterprize a btrfs не пробовал?

@voker57 пробовал под задачу, в которой данных не очень жалко, но нужно прозрачное сжатие zstd. вроде работало, но я не пробовал выдирать диски и эмулировать битрот, да и задача быстро свернулась. с другой стороны, > Since the official recommendation is to use the "most modern kernel possible", be ready to be friendly scolded when you report a problem while not using it. https://github.com/mosteo/btrfs-status страница, конечно, устарела года на полтора, но мне всё равно как-то стрёмно её использовать. это фейсбук может позволить себе кучу дисков и зарплату мейсона, а я нет. плюс я ещё думаю собрать raid5/6, который там официально unstable.

@voker57 а, ну и, если что, у dm-integrity простой on-disk format. если вдруг бекап просроченный окажется, выковыривать данные оттуда будет гораздо проще, чем с этих комбайнов, которых без поллитры и radare2 своими руками с диска не прочитаешь.

@enterprize у меня btrfs лет семь назад жила в тачке, где диски рандомно отваливались от контроллера. ныла в логи, справлялась, ни байта не потеряла

@stiletto а диски возвращались до ребута? какое-то время назад вроде любили ныть, что деградированный btrfs можно было смонтировать rw только один раз

@enterprize диски пропадали и возвращались по нескольку раз за аптайм

@voker57 и всё-таки вне тестовой виртуалки эта штука соснула. приходится ждать четверть века, пока integritysetup format перепишет все пустые терабайты пустотой с чексуммами, потому что если добавить --no-wipe и построить на этом mdraid, всё начинает ломаться в неожиданных местах: > Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system > [ 6577.774198] md/raid1:md127: dm-1: unrecoverable I/O read error for block 266089080 > [ 6577.774312] Buffer I/O error on dev md127, logical block 33261135, async page read > while writing > read error хотя казалось бы, просят записать — посчитай чексумму и запиши, чаво ты там назад прочитать пытаешься, а

@ceyt > Хорошо, что он в процессе работы уменьшается до нуля и может прозрачно быть размазан по неиспользуемому месту Хе-хе, примерно так space maps в ZFS и работают. Только там обнулять ничего не надо, а мапа используется лишь для поиска свободного места для записи. > ухудшенная производительность первого доступа С dm-integrity в целом на производительность рассчитывать не приходится. Можно, конечно, взять xxhash64 и выключить журнал, но последнее делать не хочется: упса может не хватить, (longterm-)ядра могут паниковать по неожиданным причинам и т. д. Но если журнал и гипотетическую отложенную инициализацию можно потерпеть, то вайп — это просто огромная куча выкинутого зря времени. Даже не знаю теперь, что делать. Пойду искать перламутровые пуговицы…