> Хотите скажу страшную тайну - реальных таких размеров не бывает. С фига ли? Потому что вам с вашим ZFS так неудобно?
> Да и размер группы не позволит это сделать.
Не позволит сделать ... что? Экстент 128 метров? IIRC группы вроде обычно крупнее 128Мб.
> Так что не надо рассказывать сказки. То что теоритически так можно
> сделать - то это не значит что так сработает.
Тем не менее, я полагаю что верхний лимит здорово больше чем 2Мб. Так себя обрубить при техническом лимите в 128 было бы глупо.
> Большая нагрузка это когда SAS шина не успевает за дисковой полкой. а
> потом ложится PCI-e. А диски еще позволяют дальше качать.
Скорее это дурной переросток с дурными bottleneck-ами. Надо же какое открытие - оказывается PCI-E тоже можно тормознуть! Если сильно постараться.
> Кэп намекает что 10 серверов с таким количеством дисков жрут сильно больше
> электричества требуют в 10 раз больше площащи под датацентр.
А также работают быстрее. За счет отсутствия кучи дурных bottleneck. Хотя тут еще зависит от того что сервак с этой кучей данных делает.
> там хранилище на 10Pb, или 60Pb.. сколько серверов потребуются с 16T
> дисками? а сколько с 160T?
Ну ок, убедил, у вас и правда дохрена данных. Так понятнее зачем вам такие странные конфиги.
> А нам не нужна - представляете? даже вредна. Отказ от posix уровня
> дает +30% производительности.
А если всю операционку переписать на хардкорном асме, оптимизнув под проц который в вон той машине - будет совсем крутота. Правда, рулить ОС и развивать ее будет неудобно. По каким-то таким причинам оси на асме целиком и не пишут. И использовать конструкции без ФС нынче желанием не особо горят, невзирая на меньший оверхед. Админить неудобно. Не, я видал экспонаты и покруче, но это была узконишевая специализированная хрень, абсолютно не гибкая. И поэтому у тебя ее никогда не будет, несмотря на то что мысль лить с диска в сеть 10Гбит железкой кушающей несколько ваттов, мизерного размера, вместо здоровенного сервера - смотрится круто. На первый взгляд. А на второй оказывается что оно из-за предельной оптимизации не гибкое.
> зачем это надо.. Да хотя бы для Swift хранилищь или чего другого
> object storage или для HPC.
На практике я вижу уход от использования подобных технологий в сторону нормальных файловых систем. И вероятно nodatacow был привинчен ораклем как раз чтобы ФС превратилась в относительно тонкий слой, когда она не очень мешается БД (особенно своим CoW), но все-таки является для админа ФСом, с работающими на ней позиксными тулзами.
> Остальной бред поскипан. Райд по объектам весьма частный случай parity declustering.
Тем не менее, достаточно логично сделано, имхо.
> Который опять же придуман был не сотрудниками btrfs.
Нынче придумано много чего. Вопрос в том кто и как это скомпонует и как это работать будет
> Знаете ли есть разница объединить за 1с или за 200с. это разные
> интервалы. я не зря сказал очень ленивые.
IIRC такие вещи в ряде ФС настраиваются. У бтрфс даже вроде есть нужные рукоятки. Я правда не собираюсь продалбывать 200 секунд данных в случае краха/слета питания/чтотамеще, поэтому в такие дебри не лез. Но помню что видел рукоятки для этого у несколких ФС. По поводу чего не допираю почему это преподносится как эксклюзивный плюс, опять же.
> Технически это может любая FS, а в рабочем состоянии есть только в zfs.
Это при том что ты сам кивал на системы перемещения/кеширования? Вот это я понимаю, лицемерие во весь рост.
> так вы определитесь - возможность встроить кэш в FS это полезная штука
> или на результат не влияет? а то вы уже запутались :)
Смотря какой кэш и что это даст. Если кэш в RAM и с управлением памятью как в ZFS - себе такое "счастье" оставьте, имхо. А в целом я не заклинен на тех или иных концепциях. В пингвине стандартная практика - делать так как лучше работает, а не так как расово верно. Поэтому если где-то кэш в ФС лучше работает - пусть в ФС будет, мне не жалко. Но тогда пусть нормально с ядром дружит на предмет возможности этот кэш урезать при необходимости выделить память программам. Иначе - нафиг нужно такое счастье. Управление памятью - прерогатива ядра. И если ФС не хочет нормально дружить с ядром по этому поводу - пусть идет в пень.
> а всего-то raid начал синкать диски в момент journal replay. Итог убитый
> диск и 2 дня на написание инструментария по выколупывания данных.
Бывают в жизни огорчения. Правда звучит как-то странно - а зачем что-то делать с журналом при noatime и только чтении?
> Поддержку 128Т запилили. причем около года назад - до этого e2fsck корежил
> файлы за пределами 32T. Режим over 128T пока не тестирован в
> e2fsprogs и ext4. честно.
Да потому что такие переростки используются полутора человеками на всю планету. Ну вот они и будут все грабли на свой лоб собирать. Чем менее популярная конфига - тем выше вероятность что будут какие-то проблемы которые вы первыми на планете обнаружили.
> Так что на свой страх и риск..
Да кто бы сомневался. А вон у бздюков ZFS вис из-за нереализованного sendfile в свое время, что не помешало этим упырям заявить что оно "стабильное". И историю заката солнца вручную на лисяре можно найти. При том ок, конкретно тот случай они в утилиты втрамбовали. А еще 100500 вариантов того как оно порушится при вылезании бэдсектора?
