подскажите по архитектуре сервиса

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

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

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

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

что-то не пойму суть предложения. поясните плиз.

http://michaelandrews.typepad.com/the_technical_times/2009/10/creating-a-hash...

Тут все понятно разжевано, причины такого изврата и решение.

тогда не понятно, как ваш ответ отвечает на мой вопрос %)

А на ваш вопрос я ответил первым предложением (ни одно из ваших решении для большого кол-ва пользователей не подходит). Хотя, несмотря на то, что вы сами интуитивно предположили малую нагрузочную способность ваших решении, вы все еще цепляетесь за них, что весьма странно.

как ваш ответ отвечает на вопрос про лимиты, и как ваш ответ отвечает на вопрос о допустимом кол-ве смонтированных ФС?

Цитирую себя: ни одно из ваших решении для большого кол-ва пользователей не подходит.

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

Или же сделайте работу с файлами через git/mercurial. Это еще лучше с учетом того, что там код. Для гита можно квоты сделать: http://stackoverflow.com/questions/10914208/is-there-a-git-server-side-hook-t...

Сделайте доступ по webdav и вебморда при создании файлов тоже пусть ходит через webdav.

это для меня наверное сложным будет...

получите локи при совместном редактировании

коды не шарятся между юзерами.

сделайте работу с файлами через git/mercurial.

там коды, размер которых очень редко превышает 1кб. мне кажется, что служебная информация для git/mercurial будет занимать больше. а если еще представить от, что уже сейчас у некоторых юзеров насчитывается около 30000 компилов, то git/mercurial тормозить будет просто нереально. имхо.

Сервис планирует быть пастбином с компилятором, или внутрибраузерной IDE?

Если первое - то первый оратор в треде предложил очень хороший вариант. Хотя можно вообще хранить не файликами, а записями в БД, как вариант. Все равно текстовики с кодом.

и тем и другим. именно по этой причине файлы решено хранить на ФС. в текущей же реализации сервиса, IDE не реализорвана, и не реализована регистрация. поэтому и нет проблемы ассоциации компилов с юзерами как и нет возможности у юзеров создавать/читать/писать файлы, и поэтому коды на самом деле хранятся в БД =)

основной вопрос все же: есть ли ограничение на суммарное кол-во монтируемых ФС?

на serverfault(http://serverfault.com/questions/421364/mounting-of-few-tens-of-thousands-of-fs) говорят что 1000000 ФС.

всем спасибо. вопрос закрыт.