> Сразу видно что комментаторы выше доклад не смотрели. Цитата вырвана из контекста.

Читал - и как уже написал, комментировать противно.

> Минутой ранее в докладе говорилось, что ребята пошли в саппорт этого
> самого проэкта, где их просто послали, а поскольку они его держали

Ну-ка а давайте теперь проверим их слова. Официально саппорт есть в списке рассылки https://groups.google.com/forum/#!forum/leoproject_leofs , и еще, разумеется, есть багтрекер (еще с 2013 года) https://github.com/leo-project/leofs/issues - где же багрепорты от этих товарищей? Или их так "послали", что вычистили и следы от заведенных ими багов?

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

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

Еще есть комьюнити Project FiFO (http://project-fifo.net/). Там для хранения данных используется LeoFS. Некоторые используют LeoFS в его составе как готовый продукт и общаются чисто в рамках того комьюнити.

> приключение. Есть люди которые используют это в проде на хотябы 100+
> узлов?

Тут, похоже, есть некоторое непонимание, зачем данная штука. Она НЕ предназначена для хранения данных на 100+ узлов. Хотя вполне может обслуживать 100+ узлов, обрабатывающих данные, но хранить их предполагается на меньшем количестве. Строго говоря, явного ограничения нет - но я бы делал на ней кластеры на 6-12 узлов, может до 20. При большом количестве узлов будут некоторые неприятности как минимум при их обслуживании, но я не хочу заострять на этом внимание (проблемы известны, со временем поправят).
(это я про узлы хранения - для обслуживания 100+ узлов обработки данных, вероятно, еще потребуется немаленькая пачка узлов-шлюзов. Именно они держат нагрузку по запросам, к счастью, их очень легко масштабировать)

Это штука, когда вам надо хранить (раздавать, использовать) большое количество объектов, в том числе маленьких (картинки, документы), при этом нужна производительность и отказоустойчивость.  В отличие от конкурирующих решений, она очень проста, надежна и высокопроизводительна на маленьких объектах. Т.е. туда можно кидать и 100 МБ объекты, и 10 КБ объекты, и все будет хорошо. Нужно закинуть миллиард объектов со средним размером 50 КБ - не вопрос, все будет достаточно быстро. Чуть подробнее отпишу ниже, где спрашивают про сравнение с lustre.
Работать с ней на уровне PUT/GET/DELETE через обычный REST API либо же получая всю функциональность (пользователи/бакеты и т.п.) через S3-совместимый API. Хорошие биндинги для S3 есть для всех популярных языков, есть интеграция с другими системами (напр. Hadoop умеет обращаться к S3), многие продукты либо нативно, либо через s3cmd или s3-fuse позволяют "просто подключить" это хранилище и хранить в нем данные. Локально и значительно дешевле амазона.

Был вот у вас NAS, на котором находятся данные, с которыми работают приложения, вы его переросли - перестало хватать места/скорости/захотелось отказоустойчивости. Вы убеждаетесь, что все ваши приложения умеют обращаться или по REST, или имеют биндинги к S3, ставите эту штуку и наслаждаетесь. (NFS-доступ по ряду причин я бы не назвал production-ready, там есть много ограничений, в которые можно упереться).