> Они выдали какому-то левому чуваку из facebook - хз чего он полез туда.До того как это сделать он явно не повисел в lkml и коллег не поспрашивал. С учетом мыла bsd@ - может, решил что тоже катит "с лопаты"? :)
> Нужной в ядре только facebook. Остальные живут на внешнем модуле.
Сам по себе фэйсбук пытается быть приличной фирмой - комитит наработки апстримам. Но вот в данном случае факапчик вышел. Крупный корп без факапов как птица без крыльев.
> видимо дань моде.
Троллинг от K-H - это сильно, это стильно!
> NVidia там останется, как и появится та ОС которую выберут.
Само по себе это не делает никому ни холодно, ни жарко.
> Не будет пиара в linux,
Пиара линуху более чем достаточно. И так поналезло маздайцев каких-то, пытающихся сделать виндопомойку.
> корпорации оттуда уйдут - скорость развития упадет до 0
У корпораций? :D А на что уйдут? Винда не адаптируется, макось не серверная толком, бзды не от мира сего. На фуксию? Хипстеры устали дрова на игогошечке писать.
А вот так дернешься, с той же убунты - и нет вокруг 25К пакетов и дебианщиков, знающих что есть продакшн. И теперь вместо apt install и работы через пару минут долботни в разы больше что-то. И вместо развития своих проектов какая-то левая возня.
> (достаточно посмотреть вклад независимых разработчиков).
Ну так со временем корпы нанимают наиболее вменяемых себе - и это все те же люди. И airlied и из редхата гамнокоду прекрасно отлупляет NAK. Даже дружбанам из интеля. Блин, он именно для этого там и обитает. Конечно можно рассматривать PM'ов и прочие QA как саботажников, но говорят что они это не для прикола.
> Так что там останется?
Да все то же что и было. HPC забавен статусно, но процент рынка довольно небольшой. Ну, кроме nvidia corp, пожалуй - но вот это их проблемы, у них кроме GPU нет ничего. И то большинство скупают зерглинги-геймеры берущие числом.
> да да. checksums хорошо подсмотрены в zfs..А потом необходимости в zfs нету.
Ну да. И вообще это работает.
> Но попробую показать на пальцах - что это все туфта.
Не соглашусь насчет туфты, поюзав это на практике.
> Вот смотри - программа записала, где-то на пути изменился байтик,
Будет CSUM ERROR: при чтении блок vs csum не сойдется. Вероятность что вторую (для особых параноиков i-ю) копию блока постигла та же участь - микроскопическая. И в этом месте теорвер уже за нас.
> или баг в ядре -
Эти господа конкретно затарились дустом. Вон syzbot ядро с kasan'ом мучает. Сам баги пишет, сам бисектит, может и мылы накосячившим шлет. Да и фс тестами обложили конкретно, btrfs'ники без ложной скромности xfs test suite юзают поболее самих XFS'ников. Миллиард хомяков фб поляну тоже вытоптали.
И если мы об этом, проприетарные модули, имхо, рушат память и дестабилизируют систему больше чем все остальное. Они намного хуже инструментированы, делаются абы как и абы кем, и особо не тестируются.
> но до вычисления checksum дошло уже поврежденное. И чем поможет ваша хваленная checksum?
Теоретически, чексумы не панацея. Потому что есть некоторые участки на которых что-то могло пойти не так. Ну там проц взглюкнул, допустим, и посчитал неверно еще когда прога файл только создавала.
Практически, чексумы...
1) Прекрасно парируют "разовые" взбрыки UNC ("bad sector") и прочей трухи из накопителя (ну там фирмваре сдурело/ребутнулось).
2) Подсвечивают явно сбойное железо задолго до того как это серьезно угробит что-то.
3) Неплохо чинит все это если есть откуда.
4) И вообще, неплохо справляется даже с откровенно дурными ситуациями. Хоть и не обязано.
> а вот T10 DIF/DIX даже не даст записать ибо checksum идет рядом с данными.
Где-то это и вариант, но далеко не везде где используется Linux.
> Посмотрим с другой стороны - зачем проверять checksum на cpu - когда
> за нас это может сделать HBA?
Может быть, затем что это делает дохрена допущений относительно железа? И вообще, как угодно но опенсорсный софт делом доказал что он куда менее стремный и более предсказуемый чем всякие мутные блобвари, делающие хрен знает что. А если это вдруг не так, это можно починить.
> А вот с поддержкой T10 в btrfs плохо, очень плохо. Особенно в рейд конфетах.
Оно как бы здорово, но вот на моем ноуте btrfs парировал рандомный бэд. А ваш вариант мне бы не помог и я бы, вероятно, систему перекатывал. Из-за 1 бэда в дофига лет. После такого showcase польза запасного парашюта понятнее :P.
> совать все в один комбайн?
Это имеет свои минусы, несомненно. И свои плюсы. Да, потенциально кто-то еще мог бы захотеть сравнимые технологии. Реально таковых нет - остальные делали здорово иначе, общего знаменателя толком нет.
> Хотя вполне можно разбить на уровни.
Оно реюзает алгоритмы и facilities ядра где это возможно. А механика с block groups, разными уровнями избыточности для данных и метаданных и проч - достаточно кастомная, остальные об этом не задумывались и у них этого нет. И инфраструктуры под это нет.
> Хотя бы как в zfs.
А его дизайн может в произвольную смесь уровней RAID и конверсию оных на лету? Вплоть до отскребания после ребута и продолжения операции с места краха?
B btrfs это следствие фокуса block groups и того что их схемы хранения могут быть разными. Это не менеджится как блочный RAID, в первом приближении можно обозвать это "пофайловым RAID", чтоли, это не точно - метаданные, допустим, не файлы, но у их блоков тоже своя схема хранения, не обязательно та же что у данных. В силу относительной уникальности такого дизайна и совершенно иных подходов у других не понятно кому эти уровни будут нужны и хотели ли они именно это в именно том же виде.
> Ах да, где там parity desclustered raid в btrs? очень полезная штука
> что бы не было bootleneck на одном из дисков.
А он в один диск сам по себе и не обязан упираться, внезапно. С его точки зрения - пишут вон те блоки. Блокам требуется такая-то схема. Оно кроит блоки под эту схему и раскидывает на девайсы где было "свободное место".
Откуда вытекает один забавный лулз: можно доткнуть хоть 1 стораж, и это даст +эн места. Без запар с размерами, числами девайсов и проч. Это просто +эн места. И допустим RAID1 в терминах этой штуки - "кинь 2 блока на 2 каких-нибудь разные девайса". Если там было 5 девайсов, очевидно, пустой 6-й позволит сделать больше таких комбо и наступает профит по месту. В сильно неидеальном случае может потребоваться ребаланс, но зачастую катит и просто воткнуть i++'й девайс и помметь +эн места. Если на остальных девайсах в сумме было свободного места как на этом - нет проблем.
Из такого же подхода следует и еще кой-что.
1) Никакого выравнивания по дискам нет.
2) Нет дисков с фокусированным парити.
3) Фигня типа бэда под одним из блоков не ведет к особым проблемам и на раз чинится. И оно даже знает какая копия верная, по чексумам.
> А вот в zfs есть, в md raid есть. в btrfs нету.
У btrfs как такового очень кастомный дизайн в этом всем - и сам по себе bottleneck такого плана там ниоткуда не следует. Как максимум там аллокатор еще не все фичи дизайна эффективно использует. И возможно что он мог бы делать какой-то load balancing умнее и информированнее, скажем, если RAID5 делать как block1+block2+blockXOR. Это можно пульнуть на вон те девайсы, а можно и на вон те, лишь бы там место еще было, и при этом вполне можно взять наименее занятые, допустим. И да, при этом нет сфокусированного тома где только parity. Есть группы блоков кидаемые по определенным правилам.
Это обеспечивает некоторые странности с сводобным местом, просто потому что ответ на вопрос о свободном месте зависит от "какую схему хранения этим блокам делать будем". Это априори неизвестно. То что сейчас оно как-бы фиксированными как бы уровнями ворочает - это просто максимально простая реализация, малость косящая под что-то привычное народу.
> В нормальных уровнях raid - 5/6 тоже "нюансы" ? ну ну.. это
Да, они не полностью доведены до ума. Как минимум write hole есть. Хотя большие головы грят что в принципе можно и заткнуть.
> предлагается пользовать mirror на объемах в 20P?
Спору нет, это не оптимально - и возможно на такой юзкейс его и не стоит здесь и сейчас. Но на этом юзкейсе мир не заканчивается.
> Опять потребности в колбасе нету?
Из тех кто активно пилил - видимо да. Это и правда достаточно нишевой случай. ИМХО логично что обладатели таких конфиг и должны пахать если им это надо и они полагают что это им может быть полезно.
> Так это и есть распределенная структура. С объемами на 10-20 P...
Семантика файловых операций никогда не делалась под распределенный параллельный доступ.
> хотя откуда от админов localhost такие объемы.
> Ничего что 1P это сейчас объем одной дисковой полки?
А теперь попробуй своей полкой налить бандвизу как ютуб, чтоли. При том им никакие дорогие переростки и не требуются - потому что они все правильно сделали.
>> Если нечто в пингвине, это показатель определенных стандартов качества.
> Спасибо посмеялся. Пиши еще :-)
Ну как бы airlied вон на днях делом подкрепил, NAKнув какое-то барахло от интела. Мне нравится когда я вижу такое отношение к делу.
