Да, это я понял, потом сделал ls - на 30 минутах тоже заебало ждать

/repo/images/$name/$date/ - тут делаю ls -l real 0m0.044s user 0m0.000s sys 0m0.000s

не надо -l

Ещё раз повторю вопрос, причём тут скрипты и хеши?

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

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

извини. все ФС не очень работают, когда миллионы файлов на одном уровне. и, хм, select * from tbl where path like '/bla/huemoe/%' order by path desc; в твоей базе тоже будет выполняться довольно долго, в основном по причине большой величины списка.

Но postgresql работает в разы лучше, чем это было на mysql

населектить это дешево, что в mysql, что в postgresql. печаль в том, что там данных - мегабайты. это не будет работать за 10 мс. ты покажи лучше time ls -f > /dev/null в этой директории

населектить это дешево, что в mysql, что в postgresql. печаль в том, что там данных - мегабайты. это не будет работать за 10 мс. ты покажи лучше time ls -f > /dev/null в этой директории

time ls -f > /dev/null real 2m6.859s user 0m0.028s sys 0m0.072s

У меня путь прямой ходит хорошо,

станет все понятно

посмотреть бы на структуру

мне непонятно, чем у него 2 минуты занимается ls выше. 52М файлов - не повод.

внутри свифта реляционная бд (:

У меня вот chown уже двадцатую минуту работает )

чем же Azure не вариант?