> Я вот например сильно сомневаюсь что вы хорошо разбираетесь в кишках ерлангового
> кода LeoFS, давайте теперь буду говорить "ну, вы не понимаете как
> там что взаимодействует" и прочую ерунду.Не разбираюсь - но в том-то и фишка, что оно "со стороны" в достаточной степени просто, чтобы понимать достаточно.
>> Т.к. фичи нет, то в документации про нее напрямую и не написано - логично?
> А, т.е. вы опять меня читали по диагонали. Я вам сказал что
> "да, такой фичи нет", вы мне: "нет, фичи нет!" О_о И
Вы лучше дайте ответ про контрольные суммы - на вопросы из предыдущего комментария. А то некрасиво получается, говорите, что они есть, а показать это в документации не хотите. Я вот так читаю документацию, что их нет. И нет, то, как оно сравнивает одну реплику относительно другой не интересно. Интересно, как оно сравнивает с эталоном - тем, что изначально было записано.
>> Вы просто не хотите понять.
> Нет, это просто вы не хотите понять что оказались в некрасивой ситуации
> когда выяснилось что большая часть из того что вы наговорили конкретно
> про Ceph - ерунда :) Как про остальное - не знаю.
Что именно, про сложность и что из-за этого сложно будет восстанавливать?
>> Вкратце: нет, на таких нагрузках это не будет работать, надо использовать через S3 API.
> Ясно, спасибо. С переделкой в объектное хранилище в принципе и Ceph заработает
> так как надо. Идея найти что-то требующее минимального перекраивания архитектуры. Хотя
> скорее всего это нереально.
Если у вас такие хитрые потребности (хранить многогигабайтные объекты), я бы смотрел на что-то другое, только и всего. Хотя вон Project FiFo использует LeoFS для хранения образов VM и снапшотов и им нравится - когда там выбирали хранилище, LeoFS оказался самым быстрым (во всяком случае, сильно обгонял RiakCS). Просто с моей точки зрения это несколько сомнительно.
>> Давайте тогда задам встречный вопрос про ceph
> Непонятно к чему этот вопрос. То что будет проблема на огромном количестве
> мелких объектов - никто никогда не спорил. Не только в листинге
В смысле? Это я из реальной задачи, между прочим. Есть файлы (картинки, бинарники, не важно), разброс 0 байт - 20 мегабайт. Распределение такое, что среди них много мелких. Средний размер выходит 70 КБ, нужно, чтобы быстро работало и с мелкими объектами, но и не тормозило на крупных. Вот прямо сейчас на каждом узле LeoFS лежит что-то типа 160 млн объектов (заполнение узлов где-то 50%) и по скорости все очень быстро. Вообще никаких проблем с айнодами, записью, чтением и т.п. И ему реально по фигу, на какой FS это находится физически. На каждом из 4 дисков находится по 64 контейнера (каждый контейнер это AVS-файл + LevelDB база из нескольких файлов), метаданные легко кэшируются и не дают оверхеда на ФС.
Я, в целом, не имею понятия, насколько это бы хорошо лежало в Ceph при тех же ресурсах. В файловой системе или в Swift - нереально.
> не актуально т.к. мы используем Ceph как СХД а не как
> хранилище метрик (что само по себе странно но в целом не
> противоречит концепции объектного хранилища, наверное).
Ну имхо это несколько странная идея, хранить метрики в объектном хранилище, имхо для этого лучше NoSQL базу взять, HBase к примеру. Впрочем, думаю, возможно все.
