> можно спросить - вы что нить кроме 1 диска в системе пользовали?
> ну так что бы 20-40-80 дисков было в NAS?

До пары десятков дисков собирал. Ну, работало. А чего ему не? Правда RAID1, конечно, а не RAID56. Хотя конечно можно как пох, выбрать самое глупое и проблемное действо и потом показательно корчиться с простреленной пяткой.

> если нет - тогда давайте закрывать разговор. Вы все равно не поймете этих проблем.

Я не утверждаю что btrfs - серебряная пуля на вообще все оказии и что это оптимально для ВСЕХ конфигураций и требований.

> Давайте я вам скажу - что journal checksum в ext4 (относительно не
> большой поток на самом то деле) Может ощутимо тормозить всю систему.

Может. И чексумы в btrfs - могут. Смотря по ситуации. Сколь-нибудь большие или странные конфиги всегда требуют к себе внимания и могут подкинуть странностей. И чего?

> Тут он и закончится. Наоборот начнется пиар того что лучше подходит, а
> линукс останется гикам.

Этот мир не настолько черно-белый и на HPC имени нвидии он вообще совсем не заканчивается. Так что вы имхо не дождетесь выполнения своего предсказания.

> Когда-то так же говорили про GCC. Когда FSF устроил подлянку с GPL
> v3, резко появилось LLVM/Clang и gcc стал в догоняющих.

Я б не назвал его догоняющим. Ну и в линухе "подлянка" с GPL была - ВНЕЗАПНО - изначально. Но вот проприенТарные бцды народу что-то вштыривали меньше. И поэтому сейчас остались только у самых жадных и наглых из жлоборасов. Остальным оказалось проще и дешевле делиться. Ну а смысл зажимать полтора патча? Они конкурентам погоды не делают. А жаба ради жабы - большинство более-менее живого бизнеса достаточно вменяемо чтобы преодолеть антипаттерны ради антипаттернов.

> Стоило начать отжимать бабло за немодифицированный busybox - так появился bsdl вариант.

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

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

Красивая теория. Жаль что не имеет особого отношения к практике.

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

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

> Давайте я вам расскажу - как умирали по 3-4 винта за раз,
> в полке из 40 дисков? была такая серия у WD -

Да и у сигейта веселые 7200.11 были.

> бах и 3 диска вылетело, и куда теорвер пойдет с такой
> теорией? вот declustered raid - как раз и помогал, а обычный raid6 не очень.

Для особо странных случаев btrfs ща умеет N копий делать. Ну, как RAID1, только блок не 2 раза дублируется а 3 или 4. Могли бы и больше - просто никто не просил.

> На localhost с одним винтом из домашней серии - да, наверно не
> вариант. Там хватит простых checksum.

А можно и не с одним и даже не для локалхоста. У мордокниги например были прикольные баги вида "если файл более 20 терабайтов, в полнолуние високосного года ведьмы напускают проклятье".

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

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

> Затем что больший класс ошибок может быть отловлен. Но для localhost и так сойдет.

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

> и места на винте это не занимает - правда требует спец форматирования винтов.

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

> Спасибо посмеялся. Пиши еще. Как там поживает баг 12xxx когда вешался linux при IO?

Закрыт как пофикшеный. ЧСХ много такого и правда починили. Да и не IO это был, а взаимоотношения IO <-> cache в специфичных ситуациях.

> А человечку было не до того что бы продумать. Надо было писать код. Знакомо.

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

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

Однако со временем причесали, обезглючили, оптимизнули, работать стало уже довольно прилично, так что ок фб, зюзе и даже фидоре вон.

> Слово "Декомпозиция задачи" о чем-то говорит ?

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

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

> Может. Но зачем? Просто ради понтов?

Ну вот прямо сейчас - для онлайн конверсии в другой тип райда. Прикольно выглядит.

> потребности в этой колбасе нету :-)

Кому как, кому как. Я бы с удовольствием назначил разные уровни разным файликам. Кому и тройной резерв не жалко, типа моих проектов, а кому и 1 копии хватит, типа одноразовой буиты "посмотрел, стер, вымыл руки с мылом".

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

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

> бедные клиенты.. file level raid это круто для понтов - но для
> реального масштаба плохо. объяснение этого весьма большое и лениво.

Для начала - я вот это хочу для лично себя, например. И если нечто так не умеет, это сразу -10 к моим симпатиям данной технологии. Если кто еще не понял, я вообще совсем не намерен быть сапожником без сапог. И считаю что клевые технологии должны работать в том числе и на лично мое благо. Иначе не такие уж они и клевые. Какое мне дело до твоих клиентов? А моим клиентам, внезапно, DUP на sd/emmc карте одноплатника - надежность здорово улучшает. И не то чтобы кто-то собирается ставить дисковую полку для загрузки штуки с пачку сигарет размером, это бред.

> То есть или зеркалирование (которое жрет дофига места), или потери данных. Даааа
> - выбор прямо для продакшена.

Еще умеет DUP на однодисковой конфиге. По своему прикольно. Я это на одноплатниках втулил, так что при нефатальных развалах sd/emmc задооооолго до фактического отказа early warning получается. А при разовых взглюках типа слета питания и продолба блока флеша на записи оно это тупо починит в фоне из второй копии - и все работает как батарейка энержайзер. И теорвер таки очень сильно за меня - с EXT4, я, видите ли, вообще совсем проигрываю если проблемный блок попал под какой-нибудь libc6. Система после этого просто не может выйти на режим. Ну и все, приплыли. А не прикольно теорверу проигрывать то, особенно с 1 сбойного блока раз в дофига лет.

Юзкейсы разные бывают. И да, btrfs не монструозный, ему и на такой конфиге ОК. Даже на 1-ядерном cortex A7 с 256-512 рамы нормально себя чувствует. Это вам не ZFS.

> Не спорю - для localhost это вполне себе решение под 2-3 винта..

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

> из 10 это нормальный overhead, а вот 1 из двух - это тривиально дорого. Когда
> нужно резервировать десятки.

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

> Давайте на пальцах - работаете вы в фирме - нужно поставить NAS пусть на 20 дисков..

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

> Сколько там надо будет вычесть в итоге из зараплаты?

Сферические блабла в вакууме.

> А если винтов не 20? а хотя бы 200? или 2000?

Да ктулху меня упаси от такого инженерного бреда как 1 стораж на 2000 винтов. Там 99.9% что архитекта этого булшита надо было выпереть с волчьим билетом, и давно. Умные головы говорят что лобовые подходы не всегда наилучшие. И если все приходит к вот такому - это именно тот самый случай.

> И тут рядом решение - которое не требует всех таких затрат.. Я
> могу 100% предсказать какое возьмут ;-)

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

> Куда налить?

Клиентам, Карл! Ну вот в случае гугли - видео всей планете льют, например. Да и не только видео.

> вот у меня с полки в сеть уходить 60Gbyte/s read/write (хотят 80 write/120 read
> - но пока вот так) - дальше не хватает PCIe даже на последних AMD.

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

> Таких полок около 100 в кластере - каждая может выливать столько.
> Куда вы говорите вылить терабайт в секунду? И сколько поток у Ютуба?

Около 30% трафика интернета, чтоли. А вы ваш терабайт в секунду, натурально, куда вылить то сможете в таком объеме? На соседний локалхост? Или у вас каналы по всей планете есть? А может, у вас таки и тут дурь с масштабированием? Потому что ну вот допустим юзерям видео налить таким макаром уже не получится на всю толпу. А вот распределенные структуры в этом плане заметно более сбалансированные вещицы. Так что ценность понта сферическими терабайтами в вакууме вызывает у меня определенные сомнения.

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

Потому что когда у вас дофига датацентров по всей планете - их содержание что-то стоит.

> наберите в поиске "google купил электростанцию" - вас ждет очень много открытий.

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