The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews, 26-Май-23, 23:36  [смотреть все]
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 23:36 , 26-Май-23 (1) –5 [V]
    Такое ощущение, что все эти xfs, btrfs и прочие – лишь игрушки. Ждём нормальный и стабильный ext5.
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., лох, 23:40 , 26-Май-23 (2) +9 [^]
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 23:42 , 26-Май-23 (3) +10 [^]
      Баг в ядре, чукча.
      xfs наверно единственная годная из всего зоопарка помимо ext.
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 23:48 , 26-Май-23 (4) –2
        И в чём её годность заключается?
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:01 , 27-Май-23 (5) +1
          Она довольно надежная и производительная.
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:05 , 27-Май-23 (6) +5
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 01:46 , 27-Май-23 (24) –1
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:28 , 27-Май-23 (28)
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 05:11 , 27-Май-23 (35) +2
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 20:57 , 27-Май-23 (181)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:56 , 29-Май-23 (263) +1
                    > Есть, только аппаратные,самого жёсткого диска, и уже давно.

                    Там вообще-то не чексуммы а FEC - но вот там если он не выдюжил, вариантов обычно два. Оно либо отдаст наверх IO error - UNC, либо отдаст сектор "как вышло" после FEC. В зависимости от дури фирмвари железки.

                    Со стороны ФС и райдов проблема в том что они в результате зачастую не знают какая копия верная. Штуки типа btrfs получают очевидный плюс: на какой копии данных чексум сошелся, та и правильная. Обычный RAID вообще может вытворять что угодно если вместо полной кончины девайсы стали допустим битые данные выгружать. Дальнейшее unspecified - и если чексум данных не было вы можете довольно долго не замечать это, пока в ФС что-то не развалится фатальным образом.

                    Как показал опыт с btrfs - пойти не так может совершенно все.
                    - Может глючить RAM и в конечном итоге это тоже проблема.
                    - Может глючить CPU и это тоже ведет к проблемам.
                    - Может глючить чипсет или контроллер RAID и их фирмвар (где применимо).
                    - Может быть глючный провод от диска до контроллера (SATA/SAS/etc).
                    - Фирмвари девайсов могут вытворять все что угодно и даже больше.

                    Иногда это превосходит самые дикие допущения ФСов. Скажем потерять большой регион в 16-64 мега при внезапном слете питания? Всего лишь SSD кантовал RMW/GC а тут питание слетело или сглючила фирмварь. Некоторые конфигурации типа Btrfs @ RAID1 даже имеют шансы. А вот просто RAID1 совсем не готов что 2 копии будт, как живые, только - уже вот несимметричные, и догадайтесь какая из 2 верная.

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

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

                    Zoned в btrfs приветы передавал. Правда это для host-managed актуально.

                    > производителей серверные жёсткие с усиленной контрольной суммой,там до 3 байт ошибок
                    > на 4 мгб ченить могут на аппаратном уровне.

                    У почти всех заметно более мощный FEC. Типа эн байтов на каждые 4096 сектор. Собственно с 512 на 4096 перешли чтобы улучшить соотношение data/FEC. Но наружу это если и лезет то только как UNC или как мусор вместо данных если фирмварь решила вместо UNC отдать "уж что вышло". Это однако совсем не аналог чексум ФС, потому что end-to-end проверки корректности работы железа не получается и вооон то можно прошляпить.

                    А с btrfs вон там глючный чипсет заметили, тут глючный шнурок, там глючная RAM, а там и вообще проц кривой был, а там девайс не сообщал UNC но отдавал труху. Коллекция глюкастиков основательно пополнилась. Хорошо когда чексуммы данных есть.

                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 07:47 , 29-Май-23 (272)
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:42 , 30-Май-23 (292) +1
                        >> не знают какая копия верная.
                        > Это как ? Я не беру в качестве примера ниже 5 рэйд.

                        Ну вот так. RAID1: читаем обе копии по одному смещению. Опа, они разные! И чего теперь? Мы знаем что в этом месте проблема, но понятия не имеем какая из копий правильная. В случае чексум данных все упрощается: если есть копия с неверной и копия с верной чексумой, ок, вычислили гонщика. Так можно определить проблемный накопитель/контроллер/канал/провод...

                        > Там же Рида-Соломона коды корректировки,

                        В именно RAID 5 так то всего лишь XOR. Если взять 3 девайса, и 2 блока, b1 и b2, это пишется как b1, b2, b1^b2 (XOR b1 с b2). XOR интересен тем что при вылете b1 или b2 он восстанавливается всего лишь XOR второго блока с parity. Это просто, быстро, оверхед 1/3 при 3 девайсах, меньше если девайсов больше, но - переживает только отказ 1 девайса. Если нужно больше, это уже RAID6 и вот там дополнительный parity уже будет рид соломоном. Это позволяет починить вылет и 2 устройств за раз.

                        > если код не совпадает значит диск дегрейд...

                        Для RAID5 это не сработает: мы видим что b1 ^ b2 != parity но понятия не имеем который из них неверен. Для RAID6 это уже можно попробовать. Но это ценой 2 полноразмерных блоков четности. Т.е. минимум 4 стоража, при этом оверхед 50%. Как RAID1 только тормознее и хуже. В случае например btrfs на RAID1 (и даже DUP на 1 стораже) видит какая из копий неверная и фиксит из правильной. Для большего числа дисков RAID6 может уже иметь смысл а RAID5 становится опаснее т.к. за время ребилда не должен скончаться ни 1 стораж.

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

                        Это же касается изъятия/замены девайсов, scrub, смены схемы хранения, уменьшения ФС и т.п.. Это и есть смысл терпеть те неудобства. Безгеморное управление, можно решения переиграть, они не высечены в камне. Не нравится тот уровень RAID - конвертим в другой, лишь бы места в новом фоормате хватало для фактически записанных данных. Можно даже "мягкую" конверсию: старые блоки останутся как есть, а новые с новой схемой. Вполне валидно для той механики. А на обычном RAID такие вещи лучше даже не пытаться... как угодно но это next gen технологий хранения.

                        > Так уже есть рэйды где 3 диска может развалиться и данные не потеряться.

                        Ну да. Triple parity raid. Правда, взамен придется хранить ТРИ набора блоков parity и это не менее чем 5 девайсов, иначе бессмысленно. В принципе соотношение DATA/FEC ничем таким не ограничено, даже в RAID1 если сделать 10 копий блока то до 9 можно потерять. Проблема только в том что эффективность схемы == 1/10. Нужно ли оно такое? Врядли. Потому что не спасает от сбоев проца, рам и проч например, все 10 могут оказаться испорченными и оверхед того не стоил.

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 06:36 , 30-Май-23 (305)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 19:48 , 30-Май-23 (319)
                          > Вы рассматриваете устаревшие схемы раид.

                          Устаревший - относительное понятие. Если скажем всего 2 диска есть в энной системе, то чего кроме RAID 1 там будет такой уж смысл иметь? И чем это будет лучше? Особенно если с чексумами, так что мы видим на какой из 2 копий был сбой и можно осмысленно фиксить сбои. Чексуммы не так много места занимают зато улучшают свойства схемы хранения. А в случае btrfs можно еще и при душняке с местом просто добавить, просто +1 девайс. Любой. Какой был. И будет 3-девайсовый RAID1.

                          > Сейчас эффективность и надёжность подняли,

                          Кто, где, КАК ЭТО ПОЮЗАТЬ НА МОИХ СИСТЕМАХ? Сферические сказки про супербатарейки "где-то там" уже несколько надоели, извините. Я вот хочу нормальные технологии у себя на компах, ноуте, одноплатниках и проч. А не "где-то там".

                          > в качестве примера читайте на хабре статью "Как разработчики сидели в Петербурге и тихо ели
                          > грибы, а потом написали ОС для систем хранения данных".

                          Проблема в том что поедатели грибоа - где-то там. И операционкой у меня Linux везде. А RAID может быть не центром вселенной а 1 из фич, повышающей надеженость, до кучи. Just because I can. В этом случае меня парит чтобы менеджмент был ненапряжный, дурацких требований и допушений - минимум, а чексуммы, вот, еще и диагностируемость повышают, хайлайтя при случае проблемный хардвар. В ряде случаев это early warning вообще, когда я конечно играю в рулетку, но в режиме когда теорвер уже за меня а не против меня. В мире хлипкого железа где народ хочет емко, быстро и за копейки - это сильный аргумент. Потому что расплатой за это является текучесть, сыпучесть, глюкавость, минимальные margins, ... и по другому это можно и не заметить. А потом пожалеть когда данные - в хлам.

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

                          Ох да, мне в btrfs примерно то же самое тоже очень нравится. Разок как-то на ноуте бэд вылез, да еще под метаданными. Очень приятно при этом "csum error, corrected" получить а не разлет системы в хлам. Только вот этот хайтек - у меня на ноуте. В повседневной работе. А не у каких-то мужиков из питера с кастомной операционкой где-то там. И вот что б вы мне имели предложить лучше? Ваш EXT4 который от такого под метаданными рассыпался бы вдрызг и я бы ос переставлял? Ну спасибо, только это - не хайтек и не апгрейд. Ну да, там 1 диск и DUP как схема. И - вот - конкретный пример почему оно так. Без всяких хабр.

                          > Вообще очень передовая разработка была- работает система при развале 3!!! дисков
                          > из 7 в массиве.

                          И чего? Почитайте теорию - и поймете что в принципе FEC может исправлять любой процент ошибок. Вопрос в объеме оверхеда на хранение FEC и вычислений. Ну и осмысленности полученной схемы для тех или иных задач. А что если у меня дисков всего 2-3? Там очевидно тот номер не пройдет. Более того - а у этих мужиков можно как в btrfs, просто подоткнуть 8-й диск, если 7 стало мало? И чтоб без жесткого рестрайпа всей штуки вотпрямща?

                          > Очень показательно что разработку этой компании в наглячку стали обходить-всплыли
                          > заявки на патенты за полгода (как в Японии в 80 х),

                          Японские патенты 80х должны бы уже истечь. На патенты обычно 25 лет срок.

                          > появились в других странах аналогичные !! патенты и т.д.

                          Большая часть патентов на технологии FEC либо истекла либо будет вышиблена prior art при ближайшем рассмотрении. И вы все это рассказываете тому кто умеет строить схемы избыточности под любые нужды. Но мы же про линуха и то что в майнлайне.

                          В свое время там летали забавные патчи - весьма забавный, если не ошибаюсь, ридсоломон с конфигуряемым объемом избыточности и соответственно соотношением емкости. Но столько счастья видимо народу не требовалось и тема заглохла. А вон те разговоры в пользу бедных... мне они зачем? И как это все поможет актуальные мне конфиги улучшить по свойствам? Никак? Ну тогда "let it float by itself, f...g piece of iron".

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 09:22 , 31-Май-23 (331)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:34 , 31-Май-23 (341)
                          > Это я про  книгу одного из бывших  министров промышленности,он покаялся в 15 году.

                          Это слишиом экзотичный референс чтобы на него универсально ссылаться без пояснений.

                          > Он писал как химичили и тырили технологии где возможно.

                          Да вообще так все делают. Вопрос в легальном статусе. Скажем, переизобретать лампочку накаливания каждому в своей норке независимо было бы довольно неэффективно по ресурсам. С другой стороны и совсем уж фига изобретателю как-то неправильно. В этом смысле патенты несколько адекватнее копирайта, там еще и платить за продление надо - на память о чем есть такая чудная штука как Google Patents. Кроме всего прочего это кладезь годных идей, на половину из которых их авторы все же забили, не осилив коммерциализировать. Но это ж не значит что про них надо просто забыть? Expiry патента по причине "не оплачено" прозрачно намекает :)

                          > И было дано указание патентному бюро  тоже мошенничать- на интересную патентную
                          > заявку специально задними числами оформляли приоритет заявку на японскую фирму.

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

                          > Потом  Американцам это дело надоело- и поймали специально неправильно описанными  
                          > патентами на воровстве,ВТО не хило Японию оштрафовало.....и куча японских фирм.

                          Заднее число имеет свойство вылезать - когда кто-то все же приперся в суд и/или нашел prior art. И если в россии объективный арбитраж штука спорная, то в большей части более-менее цивилизованных стран это чревато как минимум сливом судебного процесса с треском и неслабыми выплатами. Правда, даже в штатовских патентах - их оформляют совсем не гении и типовой клерк может сдуру выписать патент на что-то весьма общее и неконкретное. Правда, в суде это все же быстренько сливается.

                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:43 , 31-Май-23 (324)
                      Чувствуется опыт у человека
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 11:26 , 31-Май-23 (335)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:20 , 01-Июн-23 (348)
                    Чексуммы _данных_ верифицируют работу оборудования end to end. И ловят множество факапов которое вон то "should never happen" просто не заметит. А потом всякие кадры рассказывают страшилки про плохие файлухи рассыпающиеся "сами по себе". На поверку сейчас большая часть таких репортов оказывается связана с глюками железа выходящими далеко за допущения типовых файлух. Единственное известное исключение это рейзер где убиение тома fsck - "known issue" :)
                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 09:09 , 01-Июн-23 (362)
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 19:22 , 01-Июн-23 (373)
                        > Эх,байки времен V3.5 .В 3.6 это починили -единственное исключение chroot для виртуальных
                        > томов (виртуальные машины)

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

                        В современном мире это опасный факап. У лично меня образов других систем с тем же типом рутфс у есть. И если дев говорит что мой кейс ведет к разлету, чинить не бум, known issue, оок! Зачем мне такие технологии?

                        К тому же ядерные апи не мировая константа. С тех пор появились io_uring, folios (группы страниц, чтобы не колупать по 1 странице) и все такое. По причине появления сверхскоростного IO (что сеть, что сторажи) и нужды урезать оверхед по линии ядра соответственно. Более менее живые на это дело отрефакторились. Полутрупики на то и полутрупики и вечно держать для них легаси апи никто не будет. Выкинут вместе с дохляком.

                        > там да,обнаружив по сигнатурам знакомые файлы fsck сносило
                        > голову. Мелкие ошибки fsck нормально ремонтировало,сколько reset я пережил не счесть.

                        А у меня оно с высокой вероятностью вынесло бы ФС, по причине наличия файлов с rootfs, я системные образа собираю и виртуалки использую. И это как бы проблема класса showstopper.

                        > Но забросили эту фс :-( ,т.к ext4 более предсказуема вела,

                        Скорее, потому что технологически оно уже ничем таким не передовое, имеет ряд трудноустранимых проблем (да, в EXT4 fsck не склонен чужие файлухи вкатывать в починяемую), а разработчики самоустранились и пошли атаковать какие-то ветряные мельницы. С Reiser4/5. Не, сама идея редизайна ок, но если девы потом на майнтенанс положат не доведя до ума и не фикся баги, то такие файлухи мало кому надо, независимо от супер-технологий, извините. Роялит сочетание в целом и как оно с реальным миром и его задачами стыкуются, а не супертехнологии в 1 конкретном закутке.

                        > а вариант с очень мелкими файлами в гиганских кол-вах редко распрастранен.

                        Собсстно рейзер3 шустро работает с кучей мелочи вроде. Но по другим эксплуатационным параметрам не ахти. В частности known issue не от мира сего и разработчики которые где-то там, за денежку датарекавери предлагают, при этом понятное дело стимула чинить вон те факапы нет. Модель в стиле утят скруджа и бесплатных соленых крекеров, а если сушняк - рядом лимонад за бакс :)

            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Rootlexx, 11:04 , 27-Май-23 (78) +1
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Kuromi, 22:40 , 27-Май-23 (189)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 21:28 , 28-Май-23 (252)
            >  Она довольно надежная и производительная.

            Бугага. Переполнения LVM раздера переводит ее в RO и нарушению митаданных, спасает только reboot.

          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:08 , 29-Май-23 (258)
            > Она довольно надежная и производительная.

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

            А вон то - это то что редхат получает разогнав всех спецов блочного уровня и заменив их на каких-то индусов. Если обратить внимание, все известные кадры вокруг ФС и блочного уровня из редхата ушли так или иначе. Последним был Bacik, после него там вообще ни 1 известного кадра не оталось, какие-то нонеймы известные хзчем.

        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Виталий, 00:40 , 27-Май-23 (14) +1
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:32 , 27-Май-23 (11) +1
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:49 , 27-Май-23 (16) +1
          Капризная и жрущая много ресурсов для своей работы ФС. На BSD иногда есть смысл ее использовать. В линуксе ее функциональность составляется из комбинации ФС и LVM.
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 01:42 , 27-Май-23 (23) +1
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 06:45 , 27-Май-23 (36) –2
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., gleb, 07:57 , 27-Май-23 (40) +2
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 08:55 , 27-Май-23 (51) +1
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 09:06 , 27-Май-23 (53) –3
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., gleb, 10:50 , 27-Май-23 (70)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 11:02 , 27-Май-23 (75)
                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 11:13 , 27-Май-23 (85) –1
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 11:39 , 27-Май-23 (96)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 14:07 , 27-Май-23 (129) –1
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:09 , 29-Май-23 (264)
                          > Я не составлял багрепорт о том случае с BtrFS, мне не до
                          > того было. Ты судишь на основании систематический ошибки выжившего? Поздравляю. Весомый
                          > аргумент к твоей экспертизе, помимо неумения читать и фантазировать на тему
                          > железа, когда по факту был накопитель с ионисторами.

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

                          Более того - судя по рассылкам и чатам других ФС у них с багами все примерно так же. Т.е. сыпется все что угодно. И обычно по достаточно хорошей причине, типа мало того что некорректной работы оборудование - так еще в месте где это выходит за допущения дизайна. Скажем ни 1 фс не готова к произвольным глюкам проца. Однако ряд глюков проца может, вот, вызывать асимметрию счета чексум на чтение и запись и в этом случае детектируем. Но это работает для рандомных сбоев а не перманентного повреждения проца симметричного на сбой и при чтении и при записи (с таким процом все как правило падает до того и проблема отпадает сама собой).

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

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 07:52 , 30-Май-23 (306) –1
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:08 , 01-Июн-23 (376)
                          > Порадуете ссылочкой на багзиллу? Если захотите сослаться на боязнь деанона,

                          Титул даденый мне вами тому не способствует.

                          > расскажите, куда заливали образ в пол гигабайта с битой файловой системой,

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

                          Я слал немелкие образа, правда не девам а знакомым которым датарекавери делал, просто торентом Потому что поблочная верификация и докачка/перекачка битого для 500 гигз - аргумент. DHT-only, без трекеров и акаунтов. А чтоб левые это не скачали, сжал 7z с нормальным паролем, еще и образ раза в 2-3 сжимается заодно.

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

                          > что бы его круто посмотрели спецы.

                          Для себя я считаю что это МОЯ проблема как мне обеспечить вон то. Это же мне надо а не спецам. Если у вас иначе - ну, удачи. Ну и спецы не глупые и после недолгих переговоров с ними в чатике или почте можно устроить кастомные договоренности как и чего. Разумеется трансфер штук на сотни гиг и терабайты оговаривается "штучно" исходя из технологически возможностей сторон.

                          > И каким образом заливали.

                          Так у btrfs в send есть режим send где он только метаданные снимает, спецом для дебага. Это еще и приваси сохраняет малость, содержимого файлов там нет.

                          > По умолчанию у среднестатистического пользователя нет запасного
                          > накопителя - он просто удаляет систему и ставит родную Бесяточку.

                          Ну он и идет в вон ту датарекавери лабу и платит, если данные надо. А если умничать попытался и таки не смог - получает кратное умножение ценика. За усложнение работ. Действия без понимания что и зачем имеют свойство делать хуже чем было.

                          Лично я и не собираюсь таких тянуть в линух. Если им десяточка лучше, пусть пользуются, для меня это ничего не меняет. Я btrfs советую только продвинутым личностям которые могут врубиться в азы путешествий во времени и мультивселенных. А лучше и в азы устройства этой фс. Так будет просто, логично, понятно, удобно. Без этого всего - это как дикарю дать звездолет, при том что он уверен что планета плоская. Куда он такой полетит?

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

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

                          > Частные случаи вроде Вашего для обобщения требуют доказательств по индукции. Всему
                          > этому учат в школе.

                          У меня были более мощные учителя по части процессов вот именно разработки софта. Объяснившие некоторые эмпирические, но зато работающие в реальном мире соотношения. И это ИМХО работает лучше теоретических рассуждений. Со школьными знаниями вы никогда не разработаете мало мальски крупный и успешный софтварный проект. Да и с институтскими тоже. Потому что не рассказывают там вон то. Это можно только в большой корпе самому увидеть.

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:59 , 02-Июн-23 (387)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:18 , 03-Июн-23 (392)
                          > Так мне и не надо, поскольку мне не нужна BtrFS как таковая

                          Тут как бы дело хозяйское, но когда из вас не удается выжать даже точное сообщение об ошибке и детали, ценность такого знания, как бы это сказать... я за объективную и актуальную оценку технологий и борьбу с багами. Но по таким данным невозможно сделать никаких выводов. Даже версии кернелов не указаны, блин. Если 2.6.32 - "кто б сомневался?!". Если 6.3 как в сабже - "ORLY?!"

                          > (скрипт Шишкина до сих пор её забивает до отказа пустым пространством?

                          ХЗ. Меня интересуют реалистичные юзкейсы, похожие на мои прежде всего. И поведение фс там. Я их и тестирую. "А если рельсу?" (мужики vs лесопилка из анека) - я не против экспериментов edge case, но их ценность для меня небольшая, потому что я в них никогда не упираюсь. Более прагматичные вещи типа окончания места, даже при каком-нибудь каче торентов проблем сейчас не вызывают. Можно стереть файло и дело с концом. С каких-т о

                          > вот то-то же).

                          Если для вас файловые системы Шишкина работают лучше, пользуйтесь ими :). А ZFS мне на уровне дизайна не нравится. Не с чего этому дизайну быть быстрым. Даже не экстентный толком, архаика. А с ломовым подпором RAM что угодно быстрое, но это не заслуга файлухи и ее структур.

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

                          И кстати если уж мы о птичках, а в этом вашем ZFS дефрагер хотя-бы сделали? А то если CoW на механике забить - сами понимаете, "не очень". Оно и с обычными то "не очень" из-за душняка аллокатору. А многодисковый пул разбирать - тоже "не очень".

                          > Мне надо было пощупать разные ФС и выбрать что-то.

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

                          > Бисект тем более пустая трата времени, когда данные уже убиты.

                          С точки зрения вот именно убиения данных - там офлайн читалка без монтирования в "btrfs" встроена, с возможностью попробовать разные точки входа (CoW же не сносит старые состояния так сразу, есть >1 варианта как его пытаться распарсить). Так что если вот именно данные, именно нужны, и их вот именно вынуть надо, btrfs ИМХО не хучший в этом аспекте. Для нтфс и фат есть офлайн читалки такого типа - как коммерческие виндовые утили, конечно. Иногда очень помогают, "альтернативный парсинг" без монтирования - с недеструктивным вытаскиванием на ДРУГОЙ стораж штука очень полезная, для вот именно вытаскивания, именно максимума данных. А тут такое прям в родном тулките фс. Вот все бы так.

                          > Он мог бы помочь, если ситуация воспроизводится.

                          Это да. У меня на самом деле "интуиция" прокачана. Нечто типа чувства мащины. Я могу просто угадать что надо сделать, если видел ситуацию лично. Но без данных и ремотно это не работает. Пространство поиска слишком большое. А очевидные факапы уже давно выбиты xfs :)) test suite :) и миллиардом юзеров фэйсбука. Так что нарываться на подобный сценарий можно весьма долго и безуспешно, даже с явным желанием его сообразить.

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 17:15 , 03-Июн-23 (396)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:30 , 04-Июн-23 (412)
                          > Похоже, тут один фанат автономной ОС устроил дудос жалобами,

                          Да, бот тут иногда жесткарит, меня правда обычно не полностью выпиливает а скорее скрывает. Я это лечу "сообщить модератору -> распрячьте". Но вообще бот перегибает. Кажется, кроме жалобщика есть и вполне себе абузивные спамеры, судя по логу модерации по некоторым спамерам ну реально рожа кирпича просит. Если мы про фс хотим потрындеть, провоцировать совсем левак наверное не есть айс с их стороны.

                          > и бот всё подряд чистит. Как я понимаю, он же и экзитноды Тора своим
                          > поведением блэклистит.

                          Я пока лишь на ~70% процентов декодировал его эвристику. В остальных 30% подбешивает внезапными сносами или скрытиями сообщений. И мне кажется что спамеров возможно более 1. Хоть я и не анализировал их в деталях, так, лог модерирования посмотрел (ссылка внизу). Если обратить внимание - в логе есть и совершенно отшибленые на голову персонажи.

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:04 , 04-Июн-23 (415)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:43 , 05-Июн-23 (418)
                          > Тот персонаж, который заявлял про открутку электросчётчика

                          ...меня репортнул модерам/ботам наверное раз 5-10 и это даже потерли.

                          Я прикинул что раз так, в эту игру могут играть и двое. В ответ я репортнул оригинальное сообщение вызвавшее флейм. Вроде прокатило и его вынесли? Я не фанат игры в 1 ворота :P.

                          > (цена вопроса за одного человека наверное рублей 500, или 6 долларов;
                          > а если ему это существенно, значит за него 50% платит бюджет)

                          Да вообще лол. И к тому же - кому как а мне например летом в помещении без кондея не комфортно рядом с пень4 находиться, его выхлоп тепла ощущается прямо рожей при входе в комнату. Даже в холостом режиме. У пней4 с управлением питанием просто никаковски и с их TDP это как бы некий трабл. С стоковым кулером они еще и воют совершенно отвратительно. А кулер на такой TDP который не воет будет стоить побольше чем те мамка+проц, пожалуй.

                          > накрутил мне тогда 20 минусов. При этом он 20 раз зашёл через Тор и написал
                          > сообщения, однозначно попадающие под удаления. Бот эти айпишники занёс в серый список,

                          Ну да. Я заметил что типаж гадит и в долгу не остался репортнув его оригинальный наброс.

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

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

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 09:07 , 05-Июн-23 (420)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:18 , 06-Июн-23 (425)
                          > Гипотетически здесь три модератора, а практически у Максима нет времени во всем
                          > разбираться.

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

                          > Жалобы от Анонима на другого Анонима лишь увеличивают энтропию.

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

                          > Если тот персонаж такой активист, ну пусть своё время и тратит
                          > активнее, тем более что сносится автоматически.

                          Я ему немного в этом помогаю. С минимальными затратами моего собственного времени. Люблю асимметричные варианты :)

                          > Я застал время 4-х пней в торговле и знаю, что обычно покупали
                          > больше Селероны или АМД, а разницу вкладывали в память-видеокарту,

                          Их больше в офисы ставили. Может, кто ухватил ЭТО нашару когда те их на утилизацию стали сдавать, мало ли. У всяких корп админов иногда можно совершенно даром хардвар получить, порой он даже вполне живой, просто древний. Им иначе еще и утилизацию оплачивать придется и они даже рады если кто утащит.

                          > получая в сумме железо мощнее. Тот процессор называли кукурузным и покупался в основном
                          > ради понтов.

                          Я их видел в офисах скорее - и из за тех свойств их считали куском проблемы, а шиком считалось 64-битная амдшка, все кого я знаю бурно радовались перейда на 64-бит атлоны, оно и воздух грело сильно меньше, и 64 бита это 64 бита, как ни крути :). Это и мультимедии всякой с кодеками, компрессорами и крипто хорошо, и для "продвинутостей" есть где позажигать. Скажем SWAR на 64-бит регистре интереснее чем 32-бит, хоть там как, а в 2 раза больше lanes это в 2 раза больше lanes и фиг оспоришь.

                          > получше - торговцам Б/У его подчас складировать некуда. Теперь подозреваю, что
                          > он уже всех в своём городе обошёл и обматерил за предложения
                          > обновить его любимый процессор задаром.

                          Мне вообще в свое время эн (полу)дохлых мамок всучили чуть не насильно, с аргументом что я электроникой и компами интересуюсь. Я сперва думал что нафиг они мне. Потом купил паялку - получил полкило зачетных силовых FET нашару, продвинутые конденсаторы и заодно тренировочные кошки для отпайки BGA. А потом я обнаглел и сделал реинжиниринг некоторых преобразователей питания под свои нужды. А чо, многофазные синхронные понижайки это круто и продвинуто, тем более что даташиты есть. И изначально на десятки ампер. И совсем не обязательно именно 1 с чем-то вольта Vcore делать. Можно в принципе "что угодно ниже 12V" если немного подумать (повышать тоже можно, но сложнее и реже надо). Появился выводок для питания всякого разного от 12V ("свинцовые акумы") на продвинутых чипах, халявно. Такие чипы даже на дижикее каком заманаешься покупать, это в основном вагонами производителям мамок уходит а для DIY и мелочи слишком сложно, не особо возят.

              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:23 , 29-Май-23 (260)
                > побило, но пул восстановил), а BtrFS сама собой рассыпалась.

                Нельзя ли конкретнее?
                1) Какие были конфигурации ФС?
                2) Что конкретно было сделано?
                3) Что случилось с точностью до сообщений об ошибке?
                4) "Пул восстановил" очень растяжимое понятие, кмк. Это точно scrub проходит и не разваливается без долговременных последствий?

                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:17 , 30-Май-23 (307) –1
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 04:31 , 31-Май-23 (328)
                    > Набираю в поисковике "восстановление zfs пула", читаю по второй ссылке документацию Оркала:

                    Я наверное непонятно выразился, пардон. Мой апстрим - майнлайн, мне интересно чтобы он, и его технологии, используемые мной (включая btrfs) работали хорошо. На внемайнлайновые вещи (включая zfs) это НЕ распостраняется. Если интересно почему: я плотно подсел на апстрим, опенсорс и пользуюсь возможностями удобного, быстрого фикса багов путем пинка конкретных тушек с подробными данными о проблеме, вплоть до точного коммита (если я смог в это). Это возможно только с чистым майнлайновым кернелом актуальной версии.

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

                    > Сложности там, если и были, то с затёртой таблицей разделов. Не помню
                    > уже, что именно с ней делал. Но ничего сверхъестественного, иначе бы записал.

                    Таблицу разделов не особо сложно чинить как по мне.

                    > Не вижу смысла всё это уточнять, когда ZFS я поднял.

                    В моем случае смысл изложен выше. Ну как бы дело хозяйское.

                    > Был сделан вывод о непригодности BtrFS "для дома".

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

                    > Можно просто считать меня нубом и обывателем - вполне годное основание для вывода. ;)

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

                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 15:35 , 31-Май-23 (336) –1
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 22:39 , 31-Май-23 (343)
                        > Я поступил ровно так же, как в случае с ZFS. Набрал в
                        > поисковике "восстановление btrfs", почитал инструкции и попробовал выполнить.

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

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

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

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

                        > Плюс к этому я ещё купил новый накопитель, но "рассыпавшийся" своего часа
                        > не дождался - как всегда внезапно понадобился.

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

                        > Случилось, что при старте ОС неожиданно оказалась BtrFS немонтируема, в том числе
                        > в R/O, что несколько раз спасало. А ZFS я сам сломал.

                        Оказалась немонтируема - печально, спору нет. Но с технической точки зрения хотелось бы понять что произошло. Скажем какое сообщение было, etc. А так фигня у всех случается.

                        > "Я использую" и "посоветую другу для дома" не одно и тоже.

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

                        > Если надо просто ФС для SSD, то проще F2FS или EXT4 для консерваторов.

                        У меня F2FS не пережил power loss/system reset tests когда я оценивал идею затолкать его как ФС для одноплатников. Он быстрый, дружественный к флешу... а еще он феерично разлетается без особых усилий. И даже fsck далеко не всегда может его собрать. И если это не получилось, плана Б особо и нету. Кроме скорости и дружественности к флешу он ничего предложить не имеет. Если этого достаточно - ну, окей. И все же снапшоты системы это круто и удобно, делает основную систему чем-то похожей на виртуалки, если кто понимает multiverse и альтернативные таймлайны из sci-fi, он оценит возможность итеративно догнать систему до нужного состояния даже если изначально эксперимент не прокатил за весьма обозримое время. А в файлухах без снапшотов undo нету. Можно LVM сделать но это муторно и работает хуже.

                        На самом деле все просто: на F2FS надрывается по сути 1 кодер в самсе. На котором еще и ksmbd на минуточку. Может ли 1 чел столько нагрузки тянуть - вы наверное поняли. Это продукт корейской галерной промышленности. Со всеми вытекающими. Но да, дизайн дружественный к флещу. Впрочем, btrfs тоже флешу не враждебен, например. Для флеша логика CoW достаточно удобна, а в zoned режиме оно вообще само FTL напоминает по логике.

                        Ext4? Ну он как бы есть, как бы работает, на идеальном железе даже не особо убиваем, а если что-то все же испортилось, fsck его все же обычно чинит. Быстрый ли он? Смотря что с ним делать. И его основной минус - он не парится что будет с данными. Чексум нет. С полным журналом он тормоз, а без - можно смесь старого и нового состояний файла получить, это обычно непригодно к использованию.

                        > Если надо снапшоты, более-менее ёмкий RAID с кешем на NVMe
                        > - то как бы и нет выбора кроме ZFS.

                        ЧСХ и с оным и с btrfs (там они через bcachefs кэш делают) на этом прикольно налетает, когда затертый до дыр SSD начинает чудить. Реакция SSD на окончание ресурса это такой отдельный достаточно забавный топик.

                        Ну и вот советовать друзьям такое - реально разве что в убунте. Где проблемы стороннего модуля майнтайнеры порешают. Без этого - очень круто когда не маунтится системная файлуха потому что сторонний модуль отъехал, аж 2 раза. И тут в зависимости от юзера возможны варианты. К тому же вон те например свежую виляшку какую хотят, или еще что - значит с свежим кернелом. Так то они есть в бэкпортах и прочем но вот как там ZFS себя чувствует... использовать друзей как лабораторного мыша тоже как-то такое себе имхо. Я btrfs'а продвинутым советую, тем что сможет его плюсы оценить. Прозрачно обрисовав что сие с свежими кернелом. А любители старины типа 2.6.32 вроде поха, разумеется, успеха с этой технологией не достигнут.

                        > Если надо "на работу" - так там есть админ, пусть он убеждает.

                        Ну, я сам себе админ. Впрочем и сборщик образов систем и фиксер системных проблем. Это как раз та культура самообслуживания которая зародилась в опенсорсе. И использование вот именно возможностей, именно опенсорса. Когда при проблеме я могу гораздо более продвинуто диагностику сделать, а при острой нужде и патч для себя попытаться скроить. Вот так опенсорс получает пойнт. А если им пользоваться как виндой... ну и в чем профит? ;)

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:41 , 01-Июн-23 (361) –1
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 03:24 , 02-Июн-23 (382)
                          > Это как раз один из критериев, почему BtrFS непригодна для дома.

                          На мой вкус так я и еще эн продвинутых юзерей пользуемся этим всем - в том числе и дома, на десктопах, лаптопах, одноплатниках и роутерах (скачка файлов в фоне или торенты) всяких, и каких-то траблов с этого всего нету. А у меня с энных пор образа для одноплатников на достаточно больших выводках (сотни) на btrfs перешли. А перешли после того как разок пришлось чинить в темпе вальса одноплатник который ВНЕЗАПНО умер. По обидной причине. Там был простой EXT4. И при загрузке - вот 1 бэд случился. Зато - под libc6! Этого хватило чтобы я поимел ВНЕЗАПНОГО гимора. Я обиделся на столь дурной теорвер и стал под образа btrfs с DUP юзать, теперь 1 рандомный бэд не проблема, только в лог матюки и я знаю что да, вон там карточку неплохо б заменить, если повторяется часто, но это именно раннее предупреждение. Играть в это казино можно долго, я отловленые текучки и сыпучки под тестовые сетапы поюазл и пока даже совсем поганые в такое казино вот не проиграли чтоб 2 копии побились в 1 логическом смещении. Так теорвер ощущается намного приятнее. Моя идея в том что с законами природы глупо спорить, ими надо пользоваться на свое благо. Ну вот теорвер в свою сторону крутануть...

                          > По ZFS имеется документация от Оркала.

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

                          И чисто практически мне док с вики/readthedocs/мана вроде хватило для понимания что и куда. А со временем я из интереса немного въехал в оющую структуру этой штуки и могу достаточно осмысленно применять фичи на свое благо с минимумом проблем. А вот что с ним надо сделать чтобы он совсем умер - я не знаю. Если б знал относительно честные методы - давно б зарепортил.

                          Пока я видел только юзерей с протертыми SSD-кешами где накопители труху файлухе отдавали, без избыточности, но с такой конфигой - это сами юзеры виноваты что сделали стремный конфиг и не чекали ресурс SSD'шника до момента пока он не протерся в хламину и не начал выгружать труху просто мегабайтами, без копий этого, а на такое в общем никто их ФС не расчитан.

                          >> Разработчики, или хоть топичные форумы, чаты и рассылки сильно лучше.
                          > Это не годится. В торговле такой финт называется навязанная услуга.

                          Лол. Если за это деньги брать как рейзер, я еще пойму претензии. Но денег платить не предлагалось. Я лишь сообщил какой вариант для меня самого работал лучше всего. ИМХО отличный вариант для разумных существ имхо. А в опенсорсе еще и культура самообслживания приветствуется, если кто не в курсе. Ну а лучшее что случается это если я смог вычислить мощный баг при помощи вон того зала. А какие-то додики в интернете - они кто и почему я вообще должен на их "клевые" советы время тратить? И главное вас не смущает что сейчас полно блогеров пишут красивые слова чисто для повышения популярности бложика или потрындеть? Достоверность и актуальность этой инфы - полная лотерея. От джекпота до эпикфейла. Чтобы понять что вам подсунули надо как минимум разбираться в этом дизайне ФС и быть в теме на уровне выше среднего, а этого как раз и нету. Я и предложил прийти в места где информированность по топику заведомо выше среднего.

                          > Это SSD с ионисторами, где производитель обещает завершение операций записи
                          > при отказе питания.

                          Обещают все эти господа много где и чего, а что, где и как реально происходит по факту, в реальных условиях - сильно отдельный вопрос, требующий изучения. Ну вон у самсуней EVO некоторые версии фирмварей могут харакири себе вообще сделать если еще удумать обещаной поддержкой TRIM воспользоваться. При том не сразу, а изредка, в определенных ситуациях. Харакири, кстати, в характеристиках не обещают, но я видел достаточно юзеров с ЭТИМ, и их было столько что в майнлайне задолбались и внесли определенные модели и версии фирмварей в блеклист - для них DISCARD форсировано отключен, даже если накопитель и думает что умеет его. Ну вот такой вот оверайд с затыканием чужого фирмварного глюка на уровне кернела. Хотя нормальный фикс это фирмвару глюкастику обновить, конечно.

                          У интелей недавно тоже какие-то обсираки были с некоторыми топовыми SSD, деталей не помню уже.

                          > Слишком много действий для восстановления данных - не годится для
                          > дома. Проще взять из резервной копии и ФС снести к чертям.

                          Я как бы согласен что так быть не должно. И если б мне была известна ситуация когда вот это воспроизводится, я бы ее аннулировал, собрав максимум деталей и пинганув девов. Но у меня на данный момент все работает, потому что все что я знал я и репортнул и плотно впрягся в процесс фикса, и это возымело предсказуемый результат - баги были починены, у меня все просто работает. Да и баги были словлены "правильно", -RC ядрами, так что до реальных продакшнов и не долетели как раз. Да, прогон и валидация -RC требует некоторых затрат времени, но если я уж плотно подсел на линух в моих проектах, я знал на что шел и это... ну... такой вот левелап в линуксе и его скиллах. Когда можно стать сам себе систембилдером, сапортом и в общем-то чем-то типа OEM :). Как по мне это было лучшее что линух мог мне предложить. Хороший апгрейд из консумеров и пользователей в часть процесса :)

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 09:04 , 02-Июн-23 (388)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:33 , 03-Июн-23 (393)
                          > Вместо денег в ходу монета с чеканкой "сделай бисект".

                          Вообще - вы в чем-то правы. Паразитизм и потребццтво в более-менее живом и успешном опенсорсе не очень приветствуется. Потому что ведет к загниванию проекта и нездоровому климату в экосистеме.

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

                          И да, так то на подумать почему СССР развалился. Ну вот у вас там не удалось воспитание человека разумного. А опенсорсники более менее могут вот. Чисто технически: потребители в конечном итоге обычно встревают в технические проблемы уникальные для себя, никто с оными бороться не хочет или не может - и бай бай, проваливайте на свою дрисняточку или что там у вас, никто не будет скучать об балласте, который получив сотни халявы совсем уж не контрибутит в ответ. Это примерно как торент, можете и не аплоадить, просто будете в самом хвосте списка, получая остатки бандвиза если они есть. А если нет - их получат более полезные клиенты. И хрен такую логику обойдешь, это самозащита сообщества от разрушения.

          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 10:35 , 27-Май-23 (66) +2
            > В линуксе ее функциональность составляется из комбинации ФС и LVM.

            Спасибо, кэп. Собственно zfs так и появилась.
            С дедубликацией по сути всего 3 ФС: zfs, btrfs, xfs. Последние две нестабильные. Вот и весь выбор.
            Снапшоты, copy-on-write, сжатие, репликация - весь фарш есть. Надежность уровня production (что не отменяет необходимость бекапов, как и везде). А лишняя (конкретно в данном случае) прослойка LVM не нужна.
            Ставить zfs в старый ноут 500ГБ hdd 4ГБ ram смысла конечно нет. Но уже для домашней файлопомойки вполне.

          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 14:44 , 27-Май-23 (138)
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 08:17 , 27-Май-23 (47)
          Сложная в освоении и память жрет побольше некоторых.
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 14:46 , 27-Май-23 (139) +2
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 15:15 , 27-Май-23 (145) –1
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 16:49 , 27-Май-23 (154) –1
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 18:17 , 27-Май-23 (166) +1
                  Чего там ждать? mkfs.btrfs и все. Никаких zpool и прочего не нужно.
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:28 , 29-Май-23 (261)
                  > если тебе даже zfs сложно оказалось осилить - она тебя не дождется.

                  Btrfs заметно проще, приятнее и дружественнее в управлении. Однако чтобы с btrfs стоит почитать ман и понять основы ее устройства. Тогда dos и donts станут более очевидны.

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

                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 10:05 , 29-Май-23 (277)
                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:12 , 30-Май-23 (295)
                      > Покажите пальцем, в каком месте?

                      Добавление, замена, изъятие девайсов, рестрайп на ходу, все такое. Можно просто подоткнуть девайс если места мало. Или даже временно расширить хранилку под разовое действо, а потом вынуть добавленые девайсы. Или даже передумать насчет схемы хранения. И все это парой команд, логично, ненапряжно, шустрее чем можно было бы ожидать - благодаря backrefs и дизайну с блочными группами оно может трекать что реально аллоцировано и кантовать только это. Это управление ФС

                      > Что именно вам сложно и неприятно в банальном управлении zfs ? То
                      > что у нее не кончаются метаданные в самый неожиданный момент?

                      Ну для начала мне сложно out of tree файлухой пользоваться. Это сразу +100 к системным граблям и траблам с репортом багов в майнлайн. Еще я нахожу очень странным что дедуп только с ломовым жором ресурсов - и более никак. Финт с "reflinks" мне в этом плане очень понравился: это по смыслу стопроцентный дедуп блоков, всего лишь. Когда копия изначально на 100% дедупнута относительно оригинала. Мне нравится гибкость дизайна, типа схемы хранения DUP для 1-дисковых систем. Это намного лучше лечилова про энтерпрайз, блаблабла, и позволяет прикрутить в достаточно странные применения, типа одноплатников или ноута с 1 диском. Повышает надежность системы на этом всем. Вместо рассказов про правильное железо. Это сильно лучше чем ничего. ZFS под такие допущения не делался, так что если это не энтерпрайзная файлопомойка была... а представляешь, снапшоты например актуальны на "системном диске" а вовсе и не файлопомойке. Ну или вон к роутеру 3-терабайтник с btrfs прицеплен. По скорости как ext4, плюс-минус, RAM и CPU трескает умеренно, хорошо когда фича масштабируется вверх и вниз. И иногдя я хочу именно карманный вариант героя.

                      > вас обидели разработчики zfs? Покусились на святое?

                      Ммм... скорее их обидели разработчики btrfs. В сравнении. Просто взаимодействие с btrfs'ными понравилось сильно больше. Люблю когда взаимодействия конструктивные, мощные, с работой над проблемой а не рассказами о том кому что (не)нужно, вилянием окороком и маркетингом. Хороший дизайн в маркетинговом булшите не нуждается. А так было бы интересно увидеть что Кент сделает, с учетом эксплуатации btrfs. Но это не быстрая история. Когда такие штуки быстро делались...

      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:09 , 30-Май-23 (291) [V]
        А топик как раз о том как все годно в XFS получилось? :)
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Виталий, 00:49 , 27-Май-23 (17) –4 [V]
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:06 , 27-Май-23 (19) –1
        xfs - Файловая система, производительность которой не зависит от количества и размера файлов.
        btrfs - Нестабильный комбайн.
        Снапшоты можно делать средствами LVM сто лет в обед. И остальную кучу возможностей тоже.
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Xo, 02:41 , 27-Май-23 (29)
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Виталий, 02:48 , 27-Май-23 (30)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., gleb, 08:01 , 27-Май-23 (42) +1
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:40 , 27-Май-23 (57) +2
            ext4 с коэф.записи 4 * на коэф.записи 1 для smr_hdd, сравниваем с

            btrfs с коэф.записи 26 * на коэф.записи 4 для ssd ~= 100  

            т.е. типовой 300-разовый tlc ssd можно будет переписать реально только 3 раза.
            Нуачо, хм, "нормальное" такое коммерческое решение. :)))

          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., gleb, 13:04 , 27-Май-23 (118)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 09:36 , 29-Май-23 (276)
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:35 , 30-Май-23 (297)
              > Не особо тормозит,но балансировка и дефрагментацию при домашнем применение как в старые
              > времена -раз в месяц обязательна :-( Иначе да,начнет тормозить.

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

              Балансировка вручную вообще нужна только в каких-то очень странных случаях. Когда соотношение данных и метаданных очень радикально изменилось и актуальная аллокация скажем тратит слишком много на block group метаданных. Но это некая очень экзотичная ситуация, при обычном домашнем использовании откуда бы вот это возникнет? Сам по себе block group линейный регион блоков "от сих до сих" и смысл его ворочать просто так - мало. Только чтобы расчистить и отдать место под другой тип хранения (data -> metadata или metadata -> data). Это подразумевает что их соотношение очень радикально изменилось и при вот именно обычном, десктопно-серверном применении это какая-то экзотика.

              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 09:38 , 31-Май-23 (332)
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 23:08 , 31-Май-23 (346)
                  > А почистить метаданные ?

                  Смотря что иметь в виду под очисткой. Обычно под них выделяется 1 или несколько block group, которых потом хватает с энным запасом на рандомные флуктуации. И при обычной работе оно там себе и живет. Если data/metadata ratio радикально не меняется, пустым block groups от метаданных в ощутимом количестве браться не откуда особо.

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

                  > Не забывайте что мелкие файлы могут писаться в блок метаданных.

                  Ну да. Однако это реально _мелкие_ файлы (немного менее 4 кило, вообще, конфигуряемо вроде даже). И их количество при типовом использоваини без сильных флуктуаций опять же. Какие-то резкие флуктуации, вот именно мелочи - откуда, опять же?

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

                  У меня есть и несколько SSD которые вообще никогда не дефрагались, все равно резво работают, им в разумной степени похрен да и лишние записи дефрагера им не подарок. У сабжа есть опции типа ssd, ssd_spread и discard=async. Для большей части ssd это то что доктор прописал. Можно еще commit=N добавить взяв N побольше (более 300 даст варнинг, это в секундах). Чем реже "точки консистентности", тем меньше записей и они оптимальнее. Но взамен больше свежезаписаных данных будет отброшено при крахе.

                  На механике дефраг разумеется полезен. Насколько именно - зависит от забитости и характера записей. А вот ребаланс - обычно не особо нужен, если не делали чего-то реально странное. Сами по себе чанки блочных групп расположены линейно, при аллокации они обычно не сносятся, и потому они не субъект для фрагментации сами по себе. Если много пустых образовалось, там да, имеет смысл. Но раз в месяц? Ну разве что если там реально хаотичная и активная файлопомойка.

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

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

                  Это примерно так:
                  - Если не очень популярная ФС и много воплей, значит там не вытоптали грабли пока еще. Для этого нужна толпа. Потому что разработчики все и вся в сложном дизайне не предусмотрят.
                  - Если популярная ФС и много воплей, это лишь магия количеств. Ну а у btrfs сейчас уже дофига пользователей. Один только фэйсбук поляну слонами вытоптал, напустив миллиард пользователей. Так что если оно у кого-то сыпется, возможно проблема на их стороне а не в коде этой штуки. Вот чего сейчас хватает так это глюкавого железа и юзеров которые не читают системные логи вплоть до момента когда все жестко помрет от bit rot. Тольо тогда уже поздняк.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 01:36 , 27-Май-23 (22)
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:12 , 27-Май-23 (26) +2
        >стабильна и надежна как скала

        Если компьютер не включать.

      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 07:33 , 27-Май-23 (39)
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:01 , 27-Май-23 (52) +2
        In August 2017, Red Hat announced in the release notes for Red Hat Enterprise Linux (RHEL) 7.4 that it no longer planned to move Btrfs to a fully supported feature (it's been included as a "technology preview" since RHEL 6 beta) noting that it would remain available in the RHEL 7 release series.[30] Btrfs was removed from RHEL 8 in May 2019.[31] RHEL moved from ext4 in RHEL 6 to XFS in RHEL 7.[32]

        Но,
        In 2020, Btrfs was selected as the default file system for Fedora 33 for desktop variants.[33]

        Не могут решить, что-то

      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:57 , 27-Май-23 (60)
        у Меня тут выключали свет ежедневно. Половину года... Дак вот btrfs - при пропадании питания вообще проблемы не видит. прблемы у тех кто пытается использовать встроенный raid про который пишут четко в документациях что он НЕ РАБОТАЕТ.
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 11:06 , 27-Май-23 (79)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 12:18 , 27-Май-23 (108)
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 14:30 , 27-Май-23 (135)
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 03:53 , 29-Май-23 (270)
                > А я изучал метрологию и понимаю, что эта цифра придумана только что.

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

                Представляете, лучше уронить железку у себя эн раз и посмотреть не развалится ли, чем это самое случится у кастомера и если это сколь-нибудь массово - вот это будет настоящей ж...й! И вот тут у btrfs так то плюс: fsck вообще нет, так что и интерактив с юзером для починки не требуется.

                P.s. F2FS кстати на тесте с power loss - разваливается влет. А EXT4 достаточно минимального сбоя чтения и система полностью в дауне. Один несчастный бэд под метаданными или системной либой все выносит в хлам. Такая вот занимательная метрология.

                > Железо с тех пор работает.

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

                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:46 , 30-Май-23 (310)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 05:02 , 31-Май-23 (330)
                    > Я уверен, что DEF ничего не считал, и тесты не проводил.

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

                    > Иначе он бы и написал "какого-то такого порядка", а не 1000.

                    Не знаю как он а я мог бы и ровно 1000 циклов влепить. Допустим просто накодив фирмвару МК с таким циклом и посадив его GPIO -> RESET# одноплатника. И получит система 1000 нештатных ресетов, дешево и сердито.

                    На эту тему, моя имха...
                    - Ext4, XFS - "а что вы хотели от фс без full журнала?". Наповал обычно не мрет но консистентность состояний файлов понятно где. В Ext4 полный журнал можно, но скорость будет ацтой из-за двойной записи. CoW появился как воркэраунд этой проблемы ;).
                    - F2FS норовит с позором развалиться. Да так что даже fsck собрать не всегда может. Впрочем в автоматических применениях интересных мне, сама нужда fsck и интерактива - проблема. И это довольно странно для флешовой фс которая так то для околоэмбедовки больше. Даже в смарте показывать хомяку fsck - малоперспективно, имхо.
                    - Btrfs хз, ни разу таким методом не убился, ему ребуты вообще довольно похрен и fsck при этом не надо, cow при этом как максимум потеряет некие свежие записи. У них это и на данные и на метаданные распостраняется и чего б ему при этом дохнуть - кто б его знает.
                    - JFS - хз, не тестировал особо. Он медленный и печальный, на него все уже забили.
                    - Рейзер3 разносит тома fsck'ом и это у них "known issue", даже описаны варианты как этот issue вызвать. Это делает их fsck крайне стремным тулом. А других рейзеров вообще в майнлайне нет, для меня это showstopper.

                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 15:48 , 31-Май-23 (337)
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:50 , 01-Июн-23 (350)
                        > Потому что он где-то что-то прочёл и эту инфу разносит.

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

                        > Инфа необязательно неверна, но это банальная вера, а не знания, полученные
                        > в результате опыта.

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

                        > "Ровно 1000 циклов". А не "более 1000 раз". Ну то есть, откуда
                        > он знает, что более 1000? Считал? И как он столько насчитал?)
                        > Когда погрешность всегда плюс-минус.

                        Я тоже total count не знаю, даже если я в каком-то кейсе прогнал ровно эн, я не трекаю абсолютную сумму. Зато вот например наобум взятый SSD - злопамятный, цуко, и кажет unsafe shutdown count 107. На нем была btrfs с самого начала, сколько-то там лет. И ничего, живой.

                        Unsafe shutdown count это так то - "слет питания без подачи команды на standby режим". И между нами, само это по себе может привести к серьезному факапу, когда фоновая активность фимрвари девайса типа GC и т.п. столкнется с слетом питания - и в хучшем случае - улетом чего-то размером с erase group (десятки мегов) вникуда, и если это случится (имеет полное право согласно спекам стандартов), это в принципе запроектная авария для любой известной мне ФС, если не было избыточности на другом девайсе. А если кому это не нравится, нехай UPS юзает или ноут с батарейкой дескать. Ну вот такая вот оптимизация - фирмвара живет своей жизнью и может иметь свою линию поведения. И даже профакать данные если вы нарушили протокол взаимодействия. Который вот такой - вы явно уведомляете накопитель о намерении снять питание и только посое этого имеете право питание снять. Это часть спеков стандартов. Если вы это не обеспечили, это вообще-то ваш факап, так то. И там один большой UNDEFINED что случится. Но, вот, этому экспонату 107 раз повезло. Однако вы же понимаете что это без гарантий? И если на 108 раз он пролюбит большой сегмент и фс развалится - ну, окей, у SSD есть некоторые специфичные особенности, не очень приятные с точки зрения файлух. Это частично касается и "черепицы".

        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 11:17 , 27-Май-23 (88)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 03:38 , 30-Май-23 (304)
            > Не работают только parity-raid'ы, а mirror-raid'ы - работают.

            Более того, поскольку там у метаданных и данных могут быть разные схемы хранения, ничему не противоречит метаданные как RAID1(может даже C3) а данные как RAID 5 или 6 - и вот такое комбо даже не страдает write hole'ом. А т.к. основной объем обычно данные, то эффективность по использованию места более-менее как у RAID5/6. Это сами разработчики такой финт придумали. Вроде реально работает, так сразу не разваливается.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Отражение луны, 10:34 , 27-Май-23 (65)
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Getfor, 11:25 , 27-Май-23 (92)
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 16:30 , 27-Май-23 (149)
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:23 , 27-Май-23 (176)
        Если только самому собирать kernel и добовлять пач чтобы работал riser5, а это вариант не для всех. И то это, чтобы попробовать и решить riser5 усраивает или нет.
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:53 , 27-Май-23 (179) –1
        кстати пусть разработчик 5 версии подарит нашему невте газ прому файловую систему, пусть сами её пилят, может назовут рашен фидерашен файловая система тогда может и взлетит, но есть вариант. что заберут использовать будут. а наработки открывать не будут и она 5 версия останется внутри этих корпораций.
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:55 , 27-Май-23 (180)
          или ещё кому, зелёный есть.
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:57 , 27-Май-23 (182)
          или продать. наверно уже бы продал еслибы был спрос.
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:13 , 28-Май-23 (211)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 17:54 , 29-Май-23 (288)
            "или продать. наверно уже бы продал если бы был спрос" Я это всё писал в основном не с точки зрения как заработать, а как сделать чтобы этой файловой системе дать спрос, чтобы ей пользовались. А так файловая система есть, но самому собирать kernel не для меня и масс, не вариант, не хотят так делать когда есть выбор сделать проще.
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:55 , 30-Май-23 (311)
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 05:51 , 01-Июн-23 (352)
                Проще тогда напишу свой посыл или точнее. Смысл моих слов в том, чтобы отдать файловую систему или продать где ей будут пользоваться, а потом из этого может что-то и выйдет. Как я знаю нужен кто-то кто будет отслеживать поведение этой файловой стемы на постоянной основе и добавлять на постоянной основе изменения или исправления в kernel. Сам разработчик это делать не хочет.
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 05:55 , 01-Июн-23 (353)
                  И отдать или продать тому у кого есть желание или заинтересованность и ресурс этим заниматься.
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 08:36 , 01-Июн-23 (360)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:43 , 01-Июн-23 (378)
                    Сам собери Kernel с патчем для работы Reser5 вариант не устраивающий многих, так в массы её не продвинуть, уже писал об этом. И не факт, что Reser5 будет востребована или популярна. А так да я знаю, что он не забросил файловую систему так как для новых Kernel выпускает патч.
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 03:37 , 02-Июн-23 (384)
                    > Эдуард Шишкин и хочет, и развивает свою ФС, когда находит на то время.

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

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

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

                    Да и идеи относительно практической эксплуатации ФС, возникающих при этом вызовов и траблов у него какие-то сферисеско-вакуумные. Чтобы решать проблему ее сперва хотя-бы осознать надо. Для файлух это очень сложный топик. Особенно для некстген дизайнов.

                    Чтобы сделать btrfs должен был случиться zfs, и на основе его проблем (главная из которых имхо тормоза и ресурсожоркость без подпора такого дизайна ломовыми кешами). Чтобы Кент попробовал bcachefs должен был случиться btrfs, собравший грабли такого дизайна в реальных продакшнах оптом. И вот тогда станет понятно куда двигать дальше.

                    Если кто хочет посмотреть на более правильный формат разработки nextgen nextgen'а, могу показать кой-что интересное https://lore.kernel.org/lkml/20230509165657.1735798-1-kent.o.../

                    Заметьте: хотя Кента в энный момент один аспект достал, и он откоментил от души, в целом там очень милое и конструктивное взаимодействие. Когда люди сообща решают проблемы, сообща factor out реюзабельные куски, для ВСЕХ, и проч. А не просто встают в позу как Шишкин. И вот поэтому я думаю что у Кента - получится. И у нас будет +1 файлуха. Крутая и интересная. Но если так заметить, там вон народ уже грабель откушал при попытке тестануть ФС. Даже не на уровне ФС - а на уровне сетапа виртуалки которую скриптик хотел. Вот так вот вы даете свой код другим - и узнаете много нового. Об ожиданиях, требованиях, траблах и проч. Шишкин оказался совершенно не готов столкнуться с реальным миром в этих аспектах. И пусть он хоть нобелевский лауреат при этом, толку то.

                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 09:08 , 02-Июн-23 (389)
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 18:57 , 03-Июн-23 (397)
                        > ФС и не должна быть большим проектом.

                        Теоретически, да: все мы хотим маленький, шустрый, стабильный, фичастый дизайн/код и отсутствие багов.

                        Практически, взаимоисключающие параграфы, так только FAT, с фичностью и перфомансом швах. В полной имплементации с LFN, субдиалектами и проч даже FAT не оч простой. А еще экстентики, быстрый индекс дир, сжатие, cow, управление томами в удобном виде... а теперь со всей этой фигней мы попробуем взлететь! При попытке это сделать узнаете что железо работает не так как вы себе представляли, юзеры используют ФС иначе чем вы думали, а еще интеграция с кернелом может врезать пинка.

                        Но вы можете обойтись именами 8.3, без сжатия, снапшотов, рефлинков, экстентов и удобного управления томами. В DOS обходились же.

                        > Программисты на баш и мастера копипасты там не нужны.

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

                        Архитект может накидать core дизайна, это его вызов - только у него есть big pic. Но до ума довести, прикрутить к кернелу и его подсистемам, оптимизнуть перфоманс, выловить все баги и проч в 1 морду? Не очень реалистично, извините. К тому же железки и юзеры будут делать совсем не то что вы себе вообразили. И совсем не факт что с учетом этого ваш дизайн удачен. Но вы об этом можете узнать только взаимодействуя с толпой другого народа. Без этого сферический дизайн в вакууме, летать не будет.

                        > Он выполнил все требования. Отказ ему политически мотивирован,

                        У меня иные идеи на этот счет. Человек почему-то решил что лучше всех все знает. А это не так. Кроме его соображений есть множество других. Code reuse, complexity management в кернеле. Если нечто можно сделать реюзабельно, это нужно сделать реюзабельно. Если в ядре есть фича, ее надо поюзать а не переть дубль. Или ваша реализация лучше, втянуть ее кернел и помочь другим caller перейти на нее. И так далее. Это издержки большого проекта, damage control для выживания. И это дело каждого участника. Никому не позволят утяжелять код и нагружать других без заботы о минимизации негативных эффектов на окружающих. Шишкин не понимает эти концепции и управление большими проектами вообще.

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

                        > как и в случаях с Байкал

                        Это была не лучшая страница истории, но по моему отказ пересмотрели? В конце концов драйвер - для типовой IP от synopsis чтоли, вообще.

                        > и муражирование с NTFS.

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

                        А так если кто думает что NTFS был такой особенный, вот bcachefs. И даже недовольные коменты автора. https://lore.kernel.org/lkml/20230509165657.1735798-1-kent.o.../ - но заметьте, несмотря на матюки кодера, в целом кодер понимает что ядро это как межгалактический крейсер, вы не просто приносите свой блок, его еще надо заинтерфейсить и интегрировать в это все.

                        И кстати bcachefs это как раз "лайт версия" btrfs/zfs. Но поверьте, оно относительно мелкое и простое пока это прототип у архитекта. А через 10 лет после интеграции в майнлайн, после интенсивной эксплуатации... если доживем, вернемся к этому :). Тем не менее - с учетом грабель вон тех кент сделал определенные выводы. Поэтому смог проще и быстрее. И тем не менее, если почитать дискуссию, Кент предусмотрел далеко не все, особенности кернела как большого проекта ему икнулись. Но его дискуссия мощная и конструктивная. Думаю что он при должном упрямстве пройдет квест. Он уже близок. И тут в отличие от NTFS я буду весьма заинтересован погонять этот дизайн и собрать все мыслимые грабли. Нет, вне майнлайна я это делать не буду: с одной стороны сильно менее интересно для эксплуатации, с другой, больше возни по интеграции свалится на меня. Я буду рассматривать принятие в майнлайн как тест серьезности намерений и способности к адаптиву под неидеальный мир. Кстати вотпрямща кент узнал почему "premature optimization is a root of all evil". Вооон там он с W^X столкнулся, хы. И кстати интереснейшая дискуссия на тему того как в кернеле балансируются интересы разных сторон. Если вы думали что сможете вывалить им на голову абы что, у них иные идеи на этот счет.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:18 , 27-Май-23 (174)
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:39 , 27-Май-23 (177) +1
        на всякий случай jfs2, а так их две версии jfs1 и jfs2. jfs2 обозначают как jfs. вроде так. "В операционной системе AIX существует два поколения JFS, называемых JFS (JFS1) и JFS2 соответственно. В других операционных системах, таких как OS/2 и Linux, существует только второе поколение, которое называется просто JFS. Также JFS называют файловую систему VxFS компании Veritas Software, используемую в ОС HP-UX"
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:10 , 30-Май-23 (290)
        Не точно написано. Надо так. Ext2 и jfs? Я не шучу.
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 19:33 , 01-Июн-23 (374)
        Рассматривать ещё надо как исправляется файловая система. Как я вижу для jfs после выключения или перезагрузки через обесточивание автоматически всегда запускается проверка файловой системы с следующим включением компьютера. Я не сразу это понял по этому проверял через загрузочный диск Gparted. Смотрю, оцениваю, решаю использовать или нет jfs, продолжаю использую jfs.

        GParted 1.5.0

        configuration --enable-libparted-dmraid --enable-online-resize

        libparted 3.5

        ========================================
        Устройство:    /dev/nvme0n1
        Модель:    ORCL-VBOX-NVME-VER12
        Серийный номер:    
        Размер сектора:    512
        Всего секторов:    6165626

        Головок:    255
        Секторов на дорожку:    2
        Цилиндров:    12089

        Таблица разделов:    msdos

        Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования
        /dev/nvme0n1p1    Первичный    2048    6164479    swap        linux-swap    SWAP    

        ========================================
        Устройство:    /dev/sda
        Модель:    VBOX HARDDISK
        Серийный номер:    
        Размер сектора:    512
        Всего секторов:    20971520

        Головок:    255
        Секторов на дорожку:    2
        Цилиндров:    41120

        Таблица разделов:    msdos

        Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования
        /dev/sda1    Первичный    2048    20971519            ext2    EXT2    

        ========================================
        Устройство:    /dev/sdb
        Модель:    VBOX HARDDISK
        Серийный номер:    
        Размер сектора:    512
        Всего секторов:    41943040

        Головок:    255
        Секторов на дорожку:    2
        Цилиндров:    82241

        Таблица разделов:    msdos

        Раздел    Тип    Начало    Конец    Флаги    Имя раздела    Файловая система    Метка    Точка монтирования
        /dev/sdb1    Первичный    2048    1050623    boot        ext2        
        /dev/sdb2    Первичный    1050624    41943039            jfs        

        ========================================
        Проверить на наличие ошибок и восстановить файловую систему (ext2) на /dev/sdb1  00:00:01    ( УСПЕШНО )
                 
        калибровка /dev/sdb1  00:00:01    ( УСПЕШНО )
                 
        путь: /dev/sdb1 (раздел)
        начало: 2048
        конец: 1050623
        размер: 1048576 (512.00 МиБ)
        проверить на ошибки файловую систему /dev/sdb1 и устранить их, если это возможно  00:00:00    ( УСПЕШНО )
                 
        e2fsck -f -y -v -C 0 '/dev/sdb1'  00:00:00    ( УСПЕШНО )
                 
        Pass 1: Checking inodes, blocks, and sizes
        Pass 2: Checking directory structure
        Pass 3: Checking directory connectivity
        Pass 4: Checking reference counts
        Pass 5: Checking group summary information

        329 inodes used (1.00%, out of 32768)
        18 non-contiguous files (5.5%)
        1 non-contiguous directory (0.3%)
        # of inodes with ind/dind/tind blocks: 19/9/0
        121242 blocks used (92.50%, out of 131072)
        0 bad blocks
        1 large file

        310 regular files
        6 directories
        0 character device files
        0 block device files
        0 fifos
        0 links
        4 symbolic links (4 fast symbolic links)
        0 sockets
        ------------
        320 files
        e2fsck 1.47.0 (5-Feb-2023)
        увеличить размер файловой системы, заполнив весь раздел  00:00:00    ( УСПЕШНО )
                 
        resize2fs -p '/dev/sdb1'  00:00:00    ( УСПЕШНО )
                 
        resize2fs 1.47.0 (5-Feb-2023)
        The filesystem is already 131072 (4k) blocks long. Nothing to do!

        ========================================
        Проверить на наличие ошибок и восстановить файловую систему (jfs) на /dev/sdb2  00:02:10    ( УСПЕШНО )
                 
        калибровка /dev/sdb2  00:00:01    ( УСПЕШНО )
                 
        путь: /dev/sdb2 (раздел)
        начало: 1050624
        конец: 41943039
        размер: 40892416 (19.50 ГиБ)
        проверить на ошибки файловую систему /dev/sdb2 и устранить их, если это возможно  00:02:09    ( УСПЕШНО )
                 
        jfs_fsck -f '/dev/sdb2'  00:02:09    ( УСПЕШНО )
                 
        jfs_fsck version 1.1.15, 04-Mar-2011
        processing started: 4/25/2023 12:31:24
        The current device is: /dev/sdb2
        Block size in bytes: 4096
        Filesystem size in blocks: 5111552
        **Phase 0 - Replay Journal Log
        logredo failed (rc=-274). fsck continuing.
        **Phase 1 - Check Blocks, Files/Directories, and Directory Entries
        **Phase 2 - Count links
        Incorrect link counts have been detected. Will correct.
        **Phase 3 - Duplicate Block Rescan and Directory Connectedness
        **Phase 4 - Report Problems
        File system object DF467942 is linked as: /home/name/.config/vivaldi-snapshot/Default/Service Worker/CacheStorage/379f1cbab5b08b6fc9e08681e42d8be311441c88
        Errors detected in Directory Index Table. Will Fix.
        **Phase 5 - Check Connectivity
        **Phase 6 - Perform Approved Corrections
        **Phase 7 - Rebuild File/Directory Allocation Maps
        **Phase 8 - Rebuild Disk Allocation Maps
        **Phase 9 - Reformat File System Log
        20446208 kilobytes total disk space.
        160843 kilobytes in 43895 directories.
        13469083 kilobytes in 462646 user files.
        16 kilobytes in extended attributes
        526984 kilobytes reserved for system use.
        6610968 kilobytes are available for use.
        Filesystem is clean.
        увеличить размер файловой системы, заполнив весь раздел  00:00:00    ( УСПЕШНО )
                 
        mkdir -v /tmp/gparted-YLtEoO  00:00:00    ( УСПЕШНО )
                 
        Создан каталог /tmp/gparted-YLtEoO
        mount -v -t jfs '/dev/sdb2' '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )
                 
        mount: /dev/sdb2 mounted on /tmp/gparted-YLtEoO.
        mount -v -t jfs -o remount,resize '/dev/sdb2' '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )
                 
        mount: /dev/sdb2 mounted on /tmp/gparted-YLtEoO.
        umount -v '/tmp/gparted-YLtEoO'  00:00:00    ( УСПЕШНО )
                 
        umount: /tmp/gparted-YLtEoO unmounted
        rmdir -v /tmp/gparted-YLtEoO  00:00:00    ( УСПЕШНО )
                 
        Удалён каталог /tmp/gparted-YLtEoO

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Андрей, 14:18 , 28-Май-23 (227)
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:05 , 27-Май-23 (7) +3
    Ошибка в багзилле шляпы. Возможно, напатчили лишнего эти шляпники
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 08:13 , 27-Май-23 (46) –3
    xfs зло,файлы с недокаченого торрента исчезали когда пользовался ей в позапрошлом году и сохранки. С btrfs такого уг вообще не наблюдаю.
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 08:38 , 27-Май-23 (50) –2
    XFS как раньше затирал файлы, так и сейчас продолжает, стабильность ага. Вот думаю попробовать btrfs, но там тоже проблем хватает. Забитый диск, когда точно знаешь, что это не так убивает все желание попробовать эту фс на корню. Похоже так и придется сидеть на старой доброй ext4, то же зло, но стабильное и без сюрпризов.
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 09:07 , 27-Май-23 (55) +3
    Не знаю что там про надёжность и стабильность xfs и работу с большими объёмами.
    Но сколько раз не пробовал её использовать, приходилось отказываться.
    Самый первый раз 7-8 лет назад. Развернул чистый Oracle Linux 7.1 на xfs. ФС развалилась при установке обновления, заодно превратив в фарш все разделы.
    Ладно, в прошлом году снова решил попробовать, думаю должна быть стабильна.
    Сервер Proxmox Backup Server 7.2 (Debian 11) с аппаратным RAID 10 c батарейкой на HDD корпоративного класса. Нарезал раздел на LVM под данные 16Тб и развернул xfs с настройками по дефолту.
    Всё работало нормально до момента пока данными не заняло 90% раздела через месяц.
    После этого ошибки фс, повреждения данных.
    Два раза получилось восстановить ФС штатной утилитой.
    На третий уже ничего не помогло, ФС с ошибками, они не чинятся. Данные в фарш.

    Офигенная ФС, чё сказать, 15Тб резервных копий в небытие.

    Снёс, поставил ext4, она просто работает и пофиг ей на всё, уже год без нареканий.
    Пережила уже пару отключений света.

  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., beck, 10:31 , 27-Май-23 (64) +6 [^]
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 11:06 , 27-Май-23 (80) +4
      > Прочитал обсуждение.
      > Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо.
      > Причём у всех рассказывающих либо потери данных, либо тормоза, либо и то,
      > и другое.
      > Возникает резонный вопрос, а под линукс есть хоть одна нормальная файловая система,
      >  которая просто работает? Как например NTFS?

      Да, EXT4 стабильнее всех работает, а те кто про неё пишут гадости, подсосы бутерфс от красношляпы либо просто полезные идиоты, либо на зряплате. А ты вообще жирный MS-тролль, так-то.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 11:08 , 27-Май-23 (81) –1
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 11:10 , 27-Май-23 (83) +3
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Читатель сайта, 11:15 , 27-Май-23 (86) +1
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 11:52 , 27-Май-23 (102)
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 11:58 , 27-Май-23 (105) –2
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 12:39 , 27-Май-23 (114)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 13:45 , 27-Май-23 (124) +2
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 13:58 , 27-Май-23 (126)
              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 00:20 , 28-Май-23 (201) +2
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Sw00p aka Jerom, 10:34 , 28-Май-23 (219) –3
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Прохожий, 11:01 , 29-Май-23 (280)
                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Sw00p aka Jerom, 11:36 , 29-Май-23 (282)
                      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 19:38 , 03-Июн-23 (400)
                        > а где храним эти контрольные суммы? и в каком количестве?

                        Ну вот в файлухе например можно, если это не блочный а "файловый" дизайн был. В количестве копий блока разумеется - если это нечто типа RAID1. А что, чексуммы мало места vs блок занимают, оверхеда не так уж много, ценой очень скромного оверхеда знаем какая копия верная и возможности (авто)рекавери сильно возрастают. Для штук типа RAID5 парити для блоков чексум можно и не хранить по математическим причинам, для блоков данных ессно чексумы надо.

                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Sw00p aka Jerom, 21:26 , 03-Июн-23 (404)
                        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:15 , 04-Июн-23 (411)
                          > откуда знаем? как понять чек-сумма битая или блок данных?

                          ИМХО пофиг: если не совпадает -> проблемная копия, просто берем из другой. И какая разница чексум в копии порушился или сам блок? Если у нас исправная копия есть, мы как раз и отрекаверим и блок и его чексум.

                          Эта логика на имеющихся у меня текучках и сыпучках работает изумительно, круто разворачивая теорвер в совсем другую сторону. Теперь даже на 1 неидеальном девайсе я проигрываю не "когда бэд попал под что-то важное" а "когда бэды совпали так что накрыло обе копии". И выиграть в такой джекпот при относительно редких сбоях и относительно большом числе секторов не очень реально за обозримое время. ИМХО так теорвер намного прикольнее ощущается. А всего лишь критерии проигрыша немного пересмотрели.

                          > разве не на том же устройстве они хранятся?

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

                          > кто дает гарантии "небитости" чек-сумм?

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

              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 00:52 , 28-Май-23 (202) –1
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 12:56 , 28-Май-23 (223) –2
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., dasd, 17:34 , 28-Май-23 (237)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 17:10 , 30-Май-23 (317)
                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 19:53 , 03-Июн-23 (401)
                    > Если у вас есть RAID, куча копий данных, да на кой хрен
                    > вам вообще checksums?

                    А откуда мы знаем которая из копий на райде правильная когда на отличия налетели? Ну вот для этого чексумы и надо :). Кроме того чексумы проверяют работу железа end to end.

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

                    > Или вы реально думаете, что домашние пользователи все побежали делать RAID и
                    > хранить копии данных в трёх географических разделённых местах?

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

                    > 1) Все данные - это безумно важно!
                    > 2) Нужно убиться потратить денег, чтобы их не потерять даже в случае
                    > атомной зимы!

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

                    > Почему вы cpaный enterprise уровня банка навязывайте всем - непонятно.

                    В btrfs это все может быть в виде когда этим можно даже простому юзеру пользоваться и не париться. Схему DUP на ноутбучном диске вкатить - 1 команда в командлайне. Зато рандомный бэд раз в эн лет под метаданными прекрасно пережило, парировало и вместо ВНЕЗАПНОЙ переустановки оси в мыле я занимаюсь моими проектиками. Ну а с вашими технологиями я бы вместо этого полдня пыхтел с наруливанием операционки. Что занимает сильно больше времени чем 1 команду btrfs было скроить.

                    > Вместо этого: "ВСЕ ФС Г*ВНО, ПОТОМУ ЧТО НЕТ DATA CHECKSUMMING".

                    А таки реально - гно. Я встречал довольно много юзеров у которых ВНЕЗАПНО разлетелась файлуха до немоунтабельного состояния (чаще всего NTFS). Резко и без предупреждения. Еще вчера они свои проекты делали. Сегодня винда в бсод улетает при попытке диск прицепитьб и вообще ни 1 файла не достать. А оказывается у них там оперативочка битая, процик глюкавенький, шнурок гнилой, но они узнали об этом только когда наконец какие-то метаданные фатально накрылись и драйвер ушел в страну вечной охоты. Это кстати баг драйвера, но если вам ваш проект было надо, бодаться с сапортом майков на эту тему вам вовсе не с руки. Как и выяснять почему chkdisk это не чинит. Врядли у вас есть полгода с сапортом майков переписываться, поэтому зачастую народ юзает альтернативные планы. Так я и узнал что это бывает. Потому что внезапно, я могу и с таким подарком справиться.

                    > *ля. Ржу. Корона не жмёт?

                    Пока вы тупили, штуки типа btrfs сделали продвинутые фичи довольно доступными и ненапряжными. Представляете, в конце XIX века поездку на авто приходилось готовить почти как экспедицию. А в XXI веке мы просто плюхаемся в кресло и поехали. Хотя действо то же самое. И да т.к. отсутствие чексум ведет к резким развалам без предупреждения, это реально хреново. Так что имхо у того субъкта есть пойнт. Но да, я тоже испорчен btrfs. Зато, вот, мою коллекцию глюкастиков пополнил. Несколько флех, sd-карта, тертый калач^W ссд, гнилые шнурки, мамка с кривым чипсетом, паленый проц... нормальненько так :) можно вам из этого комп свинтить, а вы и не заметите так сразу :P.

      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Kuromi, 23:07 , 27-Май-23 (191) +1
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:59 , 31-Май-23 (327)
        > Используется на более чем 2х миллиардов Android телефонах и сотнях(!) тысяч серверов.

        Математика не нужна. Миллионы школьников не могут ошибаться.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., ptr, 12:06 , 27-Май-23 (106)
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 14:52 , 27-Май-23 (142)
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:46 , 30-Май-23 (301)
      > Xfs - дерьмо, etx4 - дерьмо, btrfs - дерьмо, zfs - дерьмо.

      ...
      >  которая просто работает? Как например NTFS?

      Она умеет разваливаться в хлам ничуть не лучше и не хуже остальных. Да так что не монтируется и не чинится chkdisk'ом иной раз. В силу природы ФС это еще и без предупреждений зачастую. Т.е. все выглядело ЗБС - а сегодня оно не маунтится или драйвер в бсод летает.

      Но если что в линух завезли ядерный полноценный драйвер этсамого, так что кто NTFS хотел может его и юзать. Хоть я и не понимаю прелести в тормозной файлухе из 90х которая требует условный "fsck" и не демонстрирует вообще совсем ничего выдающегося.

    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 01:55 , 31-Май-23 (326) –1
      Нтфс говорите? Это которая гибнет после каждого третьего выключения света? Где Папка и папка это одна директория, открывающие случайные данные? Это та фс, где нет нормальных симлинков? Которая поддерживается примерно нигде (несколько кривых версий в винде, несколько кривых версий в линухе)? Эта та самая одна из медлительнейших ФС? Ну если она просто работает, то любая из ФС покажется вам вершиной технологий.
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 10:50 , 31-Май-23 (334) +1
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 20:30 , 03-Июн-23 (403)
          > Сейчас с 64 мгб кэша на жестких любая фс при резком выключение
          > может сказать -да ну его на "буй".

          Вообще-то нет. Там есть команды для предсказуемой работы с кешированием и информирование хоста о фактическом завершении записи. И только после этого файлуха маркирует вон то как записаное а до этого оно считается "in flight" и на это нельзя уповать для критичных нужд.

          Более того - в RAM хоста еще и не такой буфер и при слете питания или внезапном ребуте ТАМ пролюбится еще и не столько. Если fsync не делать, например. Самое интересное что даже чисто апликушный софт не может игнорить этот аспект под страхом мощной потери данных. Поэтому есть характерная семантика, а девайсы должны следовать определенным требованиям в реализации кеширования. Иначе файлухи имеют полное право неконтролируемо развалиться. На слет произвольных 64 мегов в любом месте никто корректно не реагирует. Если вы потеряете большой кус допустим метаданных - это достаточно критично.

          > Но обычно это не происходит,единственно что пишущие файлы вылетят в битые файлы.

          Это происходит потому что файлуха не журналила данные файла, инфо для undo/redo хватало только на метаданные и консистентность вида ФС в лучшем случае, а что там стало с файлом внутри - это очень отдельный вопрос. Потому и битый. Не будет произвольно взятая программа жрать наполовину старый, наполовину новый файл. А у виндовых ФС как я понимаю и оглавление диры иногда может пострадать, так что часть файлов оказывается как бы на месте, но как бы безымянными - потому что их дира разнесена вдрызг тем разлетом. Так что фс знает что аллокации есть но не знает как это называлось и где лежало, например.

          > И симлинки и хардлинки данная фс поддерживает, софт не поддерживал, вот в этом беда.

          От софта по логике вещей никакой особой поддержки и не надо в простых случаях.

          > буквой обозначать (кроме диска с).

          А у ядра NT унутрях вообще сильно другие пути так-то. Но вот совместимость...

          > И не особо она медлительная-замечательно тюненгуеться,

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

          А теперь то же самое в линухе с какойнить иной фс. Ну там btrfs, ext4, etc. Почему там времена сильно более культурные? И тот же миднайт за весьма обозримое время это отрисовывает вот.

          > если стальные яйца можно даже журнал отключить.

          Никак не поможет при чтении списка 50К файлов на холодную. Вот и потюниговали :)

          > А с коммерческими драйверами спокойно под линь и 60 мгб выжимали.

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

          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., maximnik0, 22:02 , 05-Июн-23 (423)
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:42 , 06-Июн-23 (426)
              > То то в новых ядрах 1,5 сек задержку перед выключением пришлось возвращать
              > (1,5 года назад). Есть команды но нет гарантии

              Да, вы знаете, фирмвары у девайсов бывают забагованые и кривые. Но это баг и нарушение спеков стандарта - и в этом случае предъявлять что либо ядру, фс и проч не айс. Если кто купил глюкало, пусть его MFRу и пеняет.

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

              Но тут стоит понимать что воркэраунд в ядре - не решает проблему нарушения девайсом семантики на которую файлухи закладывались. Практически все ФС при журналинге и проч уповают на то что вон те операции с сбросом кеша - работают. Если это не так, крахи и слет питания ведут к UNDEFINE с практически любой ФС. Что там дальше будет - да что угодно в принципе. Это факап за пределами допущений ФС. Против лома нет приема.

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

              Более того - такие приколы и у SD-card были. Нокия в свое время агресивно снимала питание с карт после команды шатдауна, как по спекам писано. И тут оказалось что как минимум Transcend спекам не соответствует и - отлично разлетается если так делать. И пришлось им ажно слать патчи в mmc подсистему ядра.

              > а про аппаратное стирание на флэшках и говорить нечего.

              Там максимальное время операций трекается машиной состояний и больше чем в спеках не будет, как максимум erase/program error в статусе чипа будет. Но пока до этого всего дойдет, там еще чертова куча кода фирмвары писаной хзкем. И у нее могли быть какие-то сильно свои идеи. Как показал пример допустим самса с EVO, иногда эти идеи бывают странные и они вот например TRIM нормално не смогли в некоторых девайсах, да так что девайс чуть не харакири себе делает с определенными сочетаниями запросов. Пришлось и это воркэраундить, заведя список гамняшек, с точностью до девайса и версии FW, их quirks, и явно избегать проблемные операции для таких.

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

              И все же, по спекам так быть не должно. И ФС пишутся все же с опорой на эти спеки. Потому что ВСЕ мыслимые глюки ВСЕХ девайсов учесть на фазе дизайна не получится. А дальше уж пытаться воркэраундить в меру талантов. И вот тут оно может прокатить а может и нет. Разумеется новый дизайн на этапе проектирования может пытаться учесть траблы предшественников, но на 100% это нереально.

      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., n00by, 16:02 , 31-Май-23 (338)
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:01 , 04-Июн-23 (405)
          > Вы путаете ФС и ОС. В NTFS это разные директории. В NTFS
          > даже 0 (байт значения 0) может быть в середине имени.

          Зато удачи там создать файл с именем "С:\CON", как минимум через WinAPI. А в линухе это валидное имя файла. И что-то мне кажется что 0x0 в человекочитаемых вещах встречается сильно реже чем ":" или "\" например.

          И тут еще можно поспорить насколько все это именно фичи. Ничерта не подозревающий софт будет довольно интересно реагировать что на C:\ что на 0x0, 0xd, 0xa, "|" и все такое прочее. Можно даже пробовать атаки в архивах, скажем файло "C:\WINDOWS\TROLOLO.DLL" - это всего лишь файл. В топе иерархии. Если в терминах *никса. Зато если его попробовать втрамбовать на винде "как есть" может выйти интересно. Аналогично с \..\..\..\..\windows\wtf.dll каким-нибудь. Для линукса вон то тоже валидное имя файла. В топе плоской иерархии. И кстати исторически это юзерам винды икаолсь, через тот же гит допустим.

  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 16:02 , 27-Май-23 (147)
    Вы новость вообще читали?

    Chris Caudle 2023-05-19 14:00:28 UTC
    Updated to kernel 6.3.3 from updates testing repository.
    Several minutes after logging in again I began to get errors indicating that some files could not be written.  Shutdown with systemctl and while rebooting a filesystem error was detected and the system dropped to single user rescue mode.

  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., onanim, 16:41 , 27-Май-23 (151) +1
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 18:40 , 27-Май-23 (167)
    Все эти исправления больше похожи на танцы с бубном. Терминам "похоже", "вроде бы", "чуть больше", "менее стабильно" и т.п. - нет места в инженерном деле.
    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 00:12 , 28-Май-23 (200) +4
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 12:49 , 28-Май-23 (222) +1
      • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., onanim, 16:50 , 28-Май-23 (231)
        • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., birdie, 17:01 , 28-Май-23 (233)
          • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., onanim, 12:51 , 29-Май-23 (284) +1
            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 02:56 , 30-Май-23 (303)
              А ядра то надеюсь десктопные, low latency? :) Т.е. как минимум preempt_dynamic/preempt_rt. Не, это надо не только тем кто с звуком работает. Но и всем кто предпочитает отзывчивый десктоп а хотя-бы и ценой потери пары пунктов в бенчмарках.

              Видите ли обычные ядра - для серверов и они bulk performance ценят выше чем латенси. А вот юзер ожидающий переключения задачи или что там еще может быть сильно иного мнения на этот счет.

              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Неуклюжий танцор, 21:02 , 01-Июн-23 (379)
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:20 , 04-Июн-23 (407)
                  > Сколько раз пробовал ставить лоу латенси ядра - никакого эффекта нигде не
                  > ощутил, даже измеримого

                  Это в основном под нагрузкой ощущается. Под тяжелым IO и тому подобным. Если вы это не делаете то и разницы не будет особой.

                  Технически есть довольно большая разница: вырубить по линии кернела длинный синхронный сискол в середине и потом доделать, временно свалив в другую задачу, или до упора динамить всех в шедулере пока он не закруглится - для неспешного IO может занять энное время, а таск при этом uninterruptable и пусть весь мир подождет. Такая вот многозадачность - подождите пока вон те тормозное IO доделают, потом задачу переключим. Это хреново если реальное время и низкая латенси интересовали, поэтому в -RT или Dynamic Preempt ядрах разрешили переключать задачи и в случае если оно долго в сисколах отвисает, вырубая это на стороне ядра. Потому и preempt - это про возможность преемптнуть начинку ядра, если стало надо. Это не совсем халявно и теряет пару процентов производительности системы, в обмен на заметно более низкий латенси под нагрузкой.

                  В самых новых ядрах типа 6.2-6.3 понятие реалтайма сильно поменялось - там вообще пытаются сделать "жесткие" гарантии поведения на манер RTOS, внедряя патчи RT_LINUX. И когда это доделают оно вообще будет RTOS. Но за вот тот реалтайм уже приличная цена в виде оверхеда. Зато он гарантированный - это конечно не столько десктопам надо, там юзер накрайняк и подождет, сколько управляющим системам и эмбедовке (управляемый промкомпьбтером процесс в реальном мире ждать никого не будет, нет в реальном мире паузы). И тут мы уже постепенно сможем сказать привет QNX и VxWorks у которых иные идеи насчет реалтайма. Но тут стоит понимать что соответствие жесткому реалтайму это очень комплексное мероприятие и совсем не факт что вы СТОЛЬКО счастья хотели. Это уже в т.ч. ценой приличного оверхеда, если так надо для обеспечения гарантий.

              • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 21:51 , 01-Июн-23 (381)
                • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:28 , 04-Июн-23 (408)
                  > сервер, перестающий обрабатывать запросы потому что очень занят сбросом буферов на диски
                  > - немного так себе сервер.

                  Да как тебе сказать? Если сервак протупит 500 мс с запросом по HTTP ты можешь особо и не заметить. А если твой десктоп будет дергаться по 500 мс с реакцией на мыша и клаву, беситься ты будешь неимоверно, имхо.

                  А вон тем, compute only которые получают батч на счет, потом цать минут его жуют и проч, вообще плюс-минус 5 секунд клина - ни о чем. А 5% перфоманса не лишние. Юзер же не смотрит на это все, оно там каким-то диспетчером очереди раскидывается, он программа, ему пофиг.

                  > Независимо от bulk performance самой этой операции.

                  Тем не менее, ряд дистров по дефолту вкатывают ядра оптимизированые на бенчи а не юзер экспериенс. А юзерам нехило понимать что UX и маркетинг с бенчами 2 большие разницы :). Туда же и космонавтов от интеля с их рекламой и фейковым TDP и нанометрами.

                  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., пох., 11:32 , 05-Июн-23 (421)
                    • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Аноним, 00:58 , 06-Июн-23 (427)
                      > увы, у меня не финтех переводящий ресурсы в ненужные криптозакорючки, с бесконечным
                      > числом инстансов в амазон, у меня олдскул бизнес.

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

                      Если HTTP серв протупит даже и секунду в хучшем варианте - 1 юзер из скадем 1 000 000 будет считать сайтик немного тормознутым. Поскольку веб и так не особо скоростной и low latency, никто особо не заметит. И можно все же bulk ядра гонять без особых предъяв - они немного маскируются неидеальностями сетей, тормознутостью сайтов и проч.

                      А если у тебя мыша словит клин на секунду, это уже будет конкретно бесить. Потому что от десктопа с нормальными обычными программами мы все же ожидаем какой-никакой интерактив. В идеале того уровня который QNX Demo Disk показывал, но за такое достаточно большой hit по перфомансу уже, увы. И вообще линь под такое сразу не делался и там довольно много что икается когда хочется реалтайм, цуко, в серьез, с _жесткими_ гарантиями годными для _реалтайм_ систем. Мне оно надо и я поэтому немного трекаю те грабли. И пока там есть весьма отличные от идеала аспекты, и их не все зарулили. Это и клинит прием оставшихся RT_LINUX патчей: оно имеет смысл только если гарантии будут реально работать.

                      > Если сервак начнет тупить внезапно и никто не вмешается - сложится сперва
                      > сервак, а потом и весь кластер.

                      Так он тупить же не по "среднему" числу RPS будет а по "хучшему времени отклика". В этом случае ничего не сложится, просто у особо невезучих юзеров время выполнения запроса будет великовато. RPS при этом в целом будет вполне ок. Но вот на десктопе такой номер не очень работает. Даже если в среднем все резво пашет но раз в час на миллион-хренадцатьпервом сисколе мышу на секунду якорит - где юзеры такой десктоп видали? Это неприятно в использовании, и возможность преемптнуть кернел чтобы другие задачи выполнить даже если чье-то IO хорошо встряло очень хорошая идея так то :)

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

                      У меня были другие идеи на этот счет, я не стал прогибаться под изменчивый мир и прогнул его под себя. И теперь умею в создание правильных образов систем для себя любимого. На случай если копро ну вот не хочется. Да, я научился билдить кернелы, а заодно и познал радости взаимодействия с ядерщиками. И да это не совсем простой путь. Но вообще это прикольно. И с этим вполне реально сделать весьма годную операционку. Потому что в целом они адекватны и любят свое дело. Просто знаний не всегда и не всем хватает.

            • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Анннннно, 15:29 , 03-Июн-23 (395) –1
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Kirikekeks, 08:01 , 29-Май-23 (273)
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., Анонус, 16:05 , 29-Май-23 (287) +1
  • В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..., DEF, 10:05 , 01-Июн-23 (363)



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

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