я тут хочу напомнить, что по ceph и openstack есть отдельный канал @pro_openstack это так, что бы не размазывалось обсуждение

зачем ceph в один канал с этой гадостью поставили? :)

зачем ceph в один канал с этой гадостью поставили? :)

backend для openstack из каропки

так получается при чтении/записи в конкретный файл нет разницы сколько в директории файлов/

есть разница, в том и дело. После определенного количества файлов в каталоге такая канитель начинается

backend для openstack из каропки

так там же swift искаропки, ceph недефолтный еще недавно был

Сессии разве не логичней хранить в Редиске?

так там же swift искаропки, ceph недефолтный еще недавно был

Swift местами ебловат

есть разница, в том и дело. После определенного количества файлов в каталоге такая канитель начинается

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

И своеобразный

Swift местами ебловат

он целиком и полностью ебловат :) и код в нем говно, я видел

но все равно по дефолту он был раньше

все работало, но простой ls в каталоге тупо намертво вешал все

Потому что надо знать что делает ls

ладно, это реально оффтоп для этого канала

)

Потому что надо знать что делает ls

т.е.? он дергает файловую систему, а что еще?

т.е.? он дергает файловую систему, а что еще?

По умолчанию он еще сортирует. А чтобы сортировать ему надо сделать stat на каждый файл

По умолчанию он еще сортирует. А чтобы сортировать ему надо сделать stat на каждый файл

а, да, точно. Вроде есть параметр, который это отключает

Там еще потом можно удивиться, что rm не работает)))

И его нужно через пайпы и xargs юзать

По умолчанию он еще сортирует. А чтобы сортировать ему надо сделать stat на каждый файл

а если просто общаться к конкретному файлу, кол-во файлов в этой директоии будет иметь значение в плане нагрузки на систему?

По умолчанию он еще сортирует. А чтобы сортировать ему надо сделать stat на каждый файл

без сортировки, естественно, просто отадем клиенту

И его нужно через пайпы и xargs юзать

ну, это я и так всегда делаю, привычка

а если просто общаться к конкретному файлу, кол-во файлов в этой директоии будет иметь значение в плане нагрузки на систему?

От файлухи зависит, вангую.

От файлухи зависит, вангую.

мб, в этом же чате рекомендовал object storage

но все равно по дефолту он был раньше

да и сейчас по дефолту

а если просто общаться к конкретному файлу, кол-во файлов в этой директоии будет иметь значение в плане нагрузки на систему?

вот поэтому люди и юзают амазон s3, он эту проблему за тебя решает и недорогой

вот поэтому люди и юзают амазон s3, он эту проблему за тебя решает и недорогой

недорогой?)) я уже подсчитал)

проже свои железки, там bandwidth дорогой

ну и место тоже не збс

А трафик у твоего хостера бесплатный?

А трафик у твоего хостера бесплатный?

это 3 сервера обслуживаются

ну любой хостер может дать цену раз в 12 ниже AWS, это правда

на трафик

например

да тысячи их. у нас capacity сетевого терабиты, я хорошо знаю цены :)

но 5000 за 31 гигабит - это тоже перебор с другой стороны. Там будет всякий трешачок типа Cogent и похожего :)

да тысячи их. у нас capacity сетевого терабиты, я хорошо знаю цены :)

а что дешелве или лучше знаете чем этот?))

но 5000 за 31 гигабит - это тоже перебор с другой стороны. Там будет всякий трешачок типа Cogent и похожего :)

вроде норм, а если в плане цены то покажите)

а если просто общаться к конкретному файлу, кол-во файлов в этой директоии будет иметь значение в плане нагрузки на систему?

Нет

а если просто общаться к конкретному файлу, кол-во файлов в этой директоии будет иметь значение в плане нагрузки на систему?

Но тебе надо иметь индекс всех файлов

Но тебе надо иметь индекс всех файлов

Зачем?

Зачем?

Тебе надо знать абсолютный путь к файлу

Тебе надо знать абсолютный путь к файлу

Он же хранится в метаданных файлухи.

Он же хранится в метаданных файлухи.

а метаданные где? в индексе

а метаданные где? в индексе

Я решил, что он имеел ввиду какой-то собственный индекс.

Я решил, что он имеел ввиду какой-то собственный индекс.

это мы про устройство объектных хранилищ тут рассуждали

Но тебе надо иметь индекс всех файлов

да, главный сервер и будет отдавать клиенту ссылку на файл

там и есть бд файлов

на редисе

и в mysql как для подсраховки на случай если редис потеряет данные

Я решил, что он имеел ввиду какой-то собственный индекс.

Именно свой собственный индекс

Потому что надо знать что делает ls

Да, неплохо знать про readdir и вот это все

Именно свой собственный индекс

Но зачем?

Держать свой собственный индекс накладно же.

Держать свой собственный индекс накладно же.

Почему?

Почему?

1. Это уже делает файлуха. 2. Если речь о миллионах файлов, то актуальность данных придется регулярно пересчитывать, так как у тебя нет никакой гарантии, что кто-то не полез и не внес изменения ручками.

Оптимально, как тут уже писали, иметь файловую структуру такой, что никакие собственные индексы хранить не нужно. Типо /2017/01/06/однозначный_признак.расшрение

1. Это уже делает файлуха. 2. Если речь о миллионах файлов, то актуальность данных придется регулярно пересчитывать, так как у тебя нет никакой гарантии, что кто-то не полез и не внес изменения ручками.

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

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

1. для этого и существуют распределенные файлухи 2. в бд файлы в проприетарном формате хранятся зачастую

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

2. Не в безопастности, а в излишнем доверии.

Что?

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

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

у меня чувство, что ты изобретаешь HDFS

ERROR: S client not available

поэтому отказаться от собственных индексов, имея их на серверах отдачи просто негибко

Вы что-то слышали про dentry cache?

будет такая неуправляемость и расбалансировака что пиздец

Вы что-то слышали про dentry cache?

ничего)

но посмотю

Вы что-то слышали про dentry cache?

Ты давай обоснуй свой фейспалм для начала

Вы что-то слышали про dentry cache?

монтировать папку для кеша сразу на удаленный сервер, да тоже идея

inode хватит?

Разве это будет считаться кешем?

Разве это будет считаться кешем?

если получиться записать удаленно файл то мы запишем что файл такой-то есть на сервер n

в редис в бд, куда угодно

если получиться записать удаленно файл то мы запишем что файл такой-то есть на сервер n

А причем тут кеш? Ты по сути хранить начинаешь метаданные о файле во всяких редисках.

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

А причем тут кеш? Ты по сути хранить начинаешь метаданные о файле во всяких редисках.

именно mp4 файлы и буду хранить на сервере отдачи, главный сервер тольк должен знать где конкретный путь где храниться файл

ф

именно mp4 файлы и буду хранить на сервере отдачи, главный сервер тольк должен знать где конкретный путь где храниться файл

Ок. Некий сторедж хранит у себя данные, где конкретно лежит файл. Нода с файлом отваливается по сферическим причинам. Дальнейшие действия, дабы не потерять производительность?

Ок. Некий сторедж хранит у себя данные, где конкретно лежит файл. Нода с файлом отваливается по сферическим причинам. Дальнейшие действия, дабы не потерять производительность?

сферическим значит баг или закончились ноды?

сферическим значит баг или закончились ноды?

Да всё что угодно. Связность потеряна. Пожар.

в любом случае я из сервера отдачи через внутренние апи могу вернуть сообщение об ошибке и перезаписать фай

л

Куда перезаписать?

перезаписать на сервер отдачи и вернуть сообщние об ошибки чтобы внести исправление на главной сервере в индекс

с новым местоположением файла

перезаписать на сервер отдачи и вернуть сообщние об ошибки чтобы внести исправление на главной сервере в индекс

У тебя сервер отдачи по условиям боевых учений выпал в даун.

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

а серверов 3

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

Тебе же отдавать файло надо, насколько понял, а не записывать

у меня в панели управление выключение сервера есть

поэтому если я буду живой я выключу его

И тогда?...

и тогда главный сервер перестанет отдавать ссылки на него