| 1.8, raver (ok), 21:53, 19/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
 А задумка-то у автора не плохая, взял и решил проблему кластерных фс как 2х2. Мелочь и большие файлы шустро будут работать, и амазон не нужен. Да ему не плохо было бы сделать авторизацию свою, хотя на старте я бы тоже предостерег всех и выпустил софт с рекомендацией ставить за nginx. Да и нечему ему торчать наружу, там же заливаются файлы.
Было бы неплохо если бы автор добавил именно "клиентскую" компрессию и шифрование а не на стороне сервера, чтобы пользователь сам мог хоть на php сжать, зашифровать, притом чем угодно и послать данные и хеадеры с указанием того чем сжато, зашифровано итп.
А обратно получать эти же хеадеры с инфой данными, чтобы логика клиента сразу могла узнать тип компрессии, шифрования и расшифровать. А то в его todo написано об этом, но не указано как именно он будет делать компрессию и шифрование. Было бы идеально, так как тогда на стороне сервера не будет хранится ни ключ ни пароль.
| | |
| |
| 2.9, xm (ok), 22:31, 19/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Было бы неплохо если бы автор добавил именно "клиентскую" компрессию
Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и сама файловая система в хранилище? Пустое это.
| | |
| |
| 3.10, syslinux (ok), 23:49, 19/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
 >> Было бы неплохо если бы автор добавил именно "клиентскую" компрессию
> Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и
> сама файловая система в хранилище? Пустое это.
Не в защите транспортного уровня дело, а чтобы предоставить такую возможность, хочешь сам зашифровал чем тебе надо конкретный файл или даже значение и отправил это в хранилище. Гибкость. Тем более на фс далеко не во всех есть шифрование, и оно там на стороне сервера только оверхед создаст. Клиент же не только curl обычный может быть, а и целое приложение типа CRM системы или еще что, которой потребуется ключи у себя держать а не на сервере хранения. Сервер лишь при выдаче зашифрованных данных отдаст сразу в заголовках тот тип шифрования который был применен к данному конкретному файлу или значению.
| | |
| |
| 4.11, xm (ok), 00:04, 20/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Шифровать это один вопрос, а сжатие - другой.
По поводу шифрования, если это хранилка то ей должно быть по барабану шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить и выдать по запросу не особенно вникая в подробности.
| | |
| |
| 5.12, syslinux (ok), 00:13, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Шифровать это один вопрос, а сжатие - другой.
А что сжатие - все тоже самое - сжали у себя конкретный файл или значение и отправили указав тип сжатия в хеадере, сервер запомнил. При обратном запросе тоже самое, сервер выдал сжатые данные и тип сжатия, который был указан вначале. Серверов хранения может быть мало, а клиентов которые заливают много, у них CPU больше, чтобы и жать и шифровать, зачем оверхед сжатия на сервере хранения делать? Единственно что на сервере надо предусмотреть, так это настраиваемый параметр добавления заголовка для выдачи обычному браузеру сжатого контента типа gzip, чтобы браузер автоматом распаковал и отобразил содержимое, а не выдал мусор gz.
В том числе можно объединить сжатие и шифрование для конкретного файла при такой схеме если это требуется.
| | |
| |
| 6.14, xm (ok), 00:16, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> А что сжатие - все тоже самое
Нет, всё не то же самое, потому что сжимать сжатое смысла, как правило, нет, как я на это и указал выше.
Резюмируя, ваши предложения при гипотетическом внедрении лишь способны существенно снизить производительность системы ради призрачных и, по сути, бессмысленных целей.
| | |
| |
| 7.15, syslinux (ok), 00:29, 20/01/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> А что сжатие - все тоже самое
> Нет, всё не то же самое, потому что сжимать сжатое смысла, как
> правило, нет, как я на это и указал выше.
а) Вы посылаете текстовый файл 100KB , он запишется как есть, тип сжатия 0(посылать в хеадере не надо).
б) Вы послаете "уже" сжатый на клиенте текстовый файл размером 25KB в формате zstd и указываете тип сжатия допустим номер 2. Этот номер 2 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 2", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый zstd файл.
в) Вы посылаете "уже" сжатый на клиенте текстовый файл размером 40KB в формате gzip и указываете тип сжатия допустим номер 1. Этот номер 1 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 1", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый gzip файл, или "обычный" браузер сам распакует и выдаст содержимое, если сервер настроен на выдачу штатного Content-Encoding хеадера.
Сам сервер ничего не жмет и ничего не распаковывает. Какая еще проблема производительности? Пишется 1 байт и все, на стороне сервера.
| | |
| |
| 8.17, xm (ok), 00:38, 20/01/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Беда нашего образования в том, что писать оно учит, а вот читать и, тем более, п... текст свёрнут, показать | | |
|
|
|
| 5.13, syslinux (ok), 00:15, 20/01/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Шифровать это один вопрос, а сжатие - другой.
> По поводу шифрования, если это хранилка то ей должно быть по барабану
> шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить
> и выдать по запросу не особенно вникая в подробности.
Так так оно и есть сейчас, за исключением того что хранилка будет получать от клиента кроме самого зашифрованного файла, еще и тип в хеадере, Чтобы обратно при запросе выдать хеадер с этим же типом. Таким образом клиент будет сразу знать что ему летит в каком зашифрованном формате, то есть логику клиента можно гибко программировать.
| | |
|
|
|
|
| 1.3, syslinux (ok), 20:14, 19/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Попробуйте, там суть в том, что в каждой папке появляется свой bolt архив. Нет смысла заливать 1 файлик размером 1KB в одну папку, надо хотябы 32 таких файлика, так как bolt создает всегда минимум 32KB файл.
Нет смысла заливать 10 000 000 мелких файлов в 1 папку, чтобы не создать огромный bolt архив. Тогда должна получится экономия, например блок 4KB в файловой в файловой системе, загрузили 64 файла по 512B в 1 болт архив получим потребление не 64 * 4KB, а всего 32KB. А у кластерных ФС зачастую блок минимальный 32-64KB, там существенная разница будет, так что да сэкономить кроме inodes еще и место возможно. Но это в теории, там размер страницы еще 4KB влияет возможно.
Оптимально 100-10000 файлов на одну папку или подпапку = на 1 болт архив, в зависимости от размера каждого загружаемого файла. Там табличка на гитхабе есть как оптимально использовать.
| | |
| 1.1, Аноним (1), 19:25, 19/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Можно в него какой-нибудь архив freedb запихнуть? Там файлы меньше сектора на диске, какой прирост можно ожидать?
| | |
| 1.2, kai3341 (ok), 20:02, 19/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > Многопоточность
Любопытно, а зачем это здесь? Тут к месту была бы асинхронность
| | |
| |
| 2.4, syslinux (ok), 20:18, 19/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Многопоточность
> Любопытно, а зачем это здесь? Тут к месту была бы асинхронность
Оно на Go, там асинхронность то есть. В сам болт архив все равно писать можно только последовательно, если запись рассматривать. Но вот если писать в разные папки, тобишь в болт архивы то пишется паралелльно.
| | |
| 2.6, Аноним (6), 20:26, 19/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
В зависимости от используемых стратегий синхронизации потоков, такой код априори асинхронен - потоки просто делают свои задачки и ничего не знаю друг о друге. Возможно тут имелась в виду JS-like асинхронность, где процессорное время одного потока квантуется и он прыгает по коллбэкам, но такой паттерн реализован во фреймворках практически любого популярного современного языка (C++/Java/C#, по крайней мере, точно). С одним лишь отличием, что делается пул из N долгоживущих потоков-воркеров (а не 1 на весь рантайм). А дальше уже как у всех - Future/Promise, либо async/await, если разрабы языка тоже посматривают на модные тенденции в плане улучшения читабельности асинхронного кода.
| | |
| |
| 3.34, funny.falcon (?), 19:14, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Практически описали рантайм Go. Правда, они решили сосредоточиться на "зеленых потоках" вращающихся на тредпуле.
| | |
|
| 2.33, funny.falcon (?), 19:13, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
BBolt - это mmap-ed хранилище. В один тред не будет ни какой конкурентности при чтении холодных данных.
Мало того, Go runtime не способен отреагировать на затупивший page fault, как он мог бы среагировать на затупивший syscall.
Потому, для хорошей производительности ещё и придется вручную GOMAXPROCS увеличивать.
| | |
| |
| 3.47, syslinux (ok), 17:37, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
GOMAXPROCS автоматом ставится по количеству CPU начиная с версии Go 1.5 .
Как бы, если вы хотите на машине с 1-м ядром использовать этот сервер, врядли это нормально для такого решения, с миллионами файлов.
| | |
|
|
| 1.5, Аноним (5), 20:20, 19/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
в общем, понятно - у них лопнула moosefs (совершенно не предназначенная для такой фигни, поскольку держит ВСЕ метаданные в оперативной памяти и по другому работать не может (код как бы есть, но как бы не алле)
в результате они написали полуработающий архиватор, умеющий отдавать файлы из моднявого архива. Но поскольку - полу - ему все еще нужен внешний nginx для работы.
Зато "проблема" выбора неадекватного софта для кластера - решена.
| | |
| |
| 2.7, ala (?), 20:44, 19/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Надо потестить, судя по опциям там таймауты то есть чтобы наружу ставить, но там нет авторизации по паролю или айпи, видимо авторы это имели ввиду, почему им nginx нужен. Где б еще столько файлов найти.
| | |
|
| 1.16, n80 (?), 00:33, 20/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Использую для аналогичного (sea)weedfs, уже несколько лет работает в проде (не без проблем, но остальное было ещё хуже). Интересно будет сравнить с этим wZD.
| | |
| |
| 2.26, Аноним (26), 13:33, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Использую для аналогичного (sea)weedfs, уже несколько лет работает в проде (не без проблем, но остальное было ещё хуже). Интересно будет сравнить с этим wZD.
И как оно? Мы в свое время побоялись её на прод пускать. С какими проблемами пришлось столкнуться? Как нагрузку держит?
| | |
| |
| 3.28, n80 (?), 15:02, 20/01/2020 [^] [^^] [^^^] [ответить] | +/– | А чего бояться, тестировать надо и, пожалуй, хотя бы ознакомиться с кодом, благ... большой текст свёрнут, показать | | |
|
|
| 1.19, Аноним (19), 09:37, 20/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Я, может, чего-то не понимаю, но что мешает использовать в таком же режиме loop-файлы с любыми файловыми системами? Не хватает метаданных в одной ФС - сделал ещё десять и подмонтировал их в нужные каталоги. Для мелких файлов - reiserfs с tail-packing, для крупных xfs и так далее.
| | |
| |
| 2.20, Аноним (20), 09:46, 20/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
то что ты, наверное, не хочешь создавать стопиццот loop-файлов вручную и обеспечивать им стопиццот точек монтирования для плохой имитации работы архиватора.
Это архив, банальный архив. Но с модными dav и http/2 интерфейсами.
Костылик вокруг неверно выбранной базовой технологии.
| | |
| |
| |
| 4.24, syslinux (ok), 11:39, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Ну насчет прям костылика я с вами не очень согласен, если вы читали todo, то там достаточно много чего будет в ближайшее время реализовано, кроме банального помещения файликов в архивчики. Да это одна из главных задач была - чтобы можно было жить где придется не меняя основное кластерное решение впринципе.
Из тяжелого в todo, только собственный дистрибьютор и FUSE, то что не получится просто и надежно сходу сделать за там 3 месяца. Дистрибьютор будет полностью отдельным компонентом, чтобы можно было обходится впринципе без кластерных фс в системах побольше, а сам текущий бекенд останется универсальным. Хотите так, хотите по другому.
| | |
|
|
| 2.23, Аноним (-), 11:38, 20/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я что-то не понимаю - что мешает просто использовать ФС с tail packing и предоставить ФС делать ФСовскую работу? Делать эрзац ФС на go в юзермоде и называть это инновацией - ну даже не знаю, хайп ради хайпа какой-то. Мол, смотрите как мы лихо научились левой пяткой правое ухо, записывайтесь в нашу школу йоги, однако!
| | |
| |
| 3.25, syslinux (ok), 11:42, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это не ФС для начала, сравнение не корректное. ФС не ограничивается одним или парочкой серверов, если делать решение побольше раз в 10-50 например. Можете сравнить это так, как будто у вас zip архивы с мелочью вместо файлов, только это не zip и с полноценными возможностями. Так что это не ФС в юзер спейсе, а архивы. То что потом туда будет похитрому приделан FUSE потом для разнообразия, это не означает, что это ФС.
| | |
| 3.39, пох. (?), 15:41, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Я что-то не понимаю - что мешает просто использовать ФС с tail packing
вероятно - то что раз люди вынуждены использовать moose - у них уже давным-давно хранилище не влезает в один корпус, при требуемых емкости и надежности?
А кластерные fs, увы, ни про какой tail fucking не знают, они вообще сексуально неразвитые.
И выбор из moose/lizard с их metadata=ram (то есть как только все данные о ВСЕХ файлах перестали влезать в оперативку одного компьютера - опачки, кластер превращается в тыкву) и gluster (для создания файла надо опросить ВСЕ узлы кластера - метаданных-то нет, поэтому надо у каждого спросить "а не лежит ли у тебя уже файл с таким же точно именем/путем?")
А они изобрели [не]банальный архиватор с webdav интерфейсом.
| | |
|
| 2.30, n80 (?), 15:14, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Я, может, чего-то не понимаю, но что мешает использовать в таком же
> режиме loop-файлы с любыми файловыми системами? Не хватает метаданных в одной
> ФС - сделал ещё десять и подмонтировал их в нужные каталоги.
> Для мелких файлов - reiserfs с tail-packing, для крупных xfs и так далее.
Для некоторых задач у ФС слишком большие (по сравнению с такими специализированными решениями) накладные расходы на один файл. При этом большая часть возможностей ФС может быть вообще не нужна (типа отдельных mode/uid/gid/atime/mtime/ctime/etc для каждого файла), но нельзя просто взять их и отключить. Не говоря уж про то, как «больно» на ФС удалять/обновлять много мелких файлов.
Соответственно, если можно читать с дисков сразу содержимое файлов и не тратить память ядра (и пропускную способность дисков) на чтение inode, не говоря уж про время на системные вызовы для открытия очередного запрошенного файла, то на том же железе можно хранить куда больше файлов и в единицу времени обрабатывать куда больше запросов.
Так в своё время мордокнига (facebook) и пришла к своему haystack, но т.к. в публичный доступ была выложена только статья, но не сама БД, у других контор с похожими нуждами начали возникать свои реализации.
| | |
| |
| 3.31, n80 (?), 15:16, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
А, и чуть не забыл: у обычных ФС нет встроенной репликации между серверами. Можно, конечно, использовать rsync (или даже костылить что-то на inotify в духе lsyncd), но это, опять-таки, будет очень «больно» на огромных каталогах.
| | |
| 3.35, Аноним (35), 22:40, 20/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>нельзя просто взять их и отключить
Так всякие raw-разделы ещё в OracleDB были.
Просто мне кажется, что если ты упираешься в ограничения ФС при работе с файлами - то ты что-то неправильно делаешь.
| | |
| |
| 4.36, n80 (?), 03:00, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Так всякие raw-разделы ещё в OracleDB были.
С OracleDB почти не имел дела, но сразу два момента:
1) тут всё-таки про свободное ПО речь, это очень важный момент
2) низкие накладные расходы, легковесность, максимизация количества обрабатываемых простых запросов в единицу времени (по сравнению с конкурентами на таком же железе) — точно не про Oracle
> Просто мне кажется, что если ты упираешься в ограничения ФС
> при работе с файлами - то ты что-то неправильно делаешь.
Полностью согласен. И вот один из путей перестать делать неправильно — положить данные в подходящую для задачи специализированную СУБД, а не в отдельные файлы в ФС общего назначения. О том и речь.
| | |
| |
| 5.37, syslinux (ok), 12:00, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?
Кто утверждает, что такое количество допустим должно быть обязательно в фс общего назначения, про кластерные забыли?
Там писал один человек, что moosefs лопнула, не лопнула, она нормально впринципе работает с такими количествами файлов, если у вас есть деньги на оперативную память, но вот ее CRC проверка фоновая проводится несколько месяцев на таких количествах, а она там однопоточная и это не регулируется. Доводить до половины миллиарда файлов или больше уже нет смысла в ней.
Вам дали способ - как упростить себе жизнь не изменяя файловую систему на какие-то решения, которые еще неизвестно как себя поведут(в плане фс изначально), в том числе оставлена без изменений работа с большими файлами, не надо заботится о волюмах, изменять пути в приложении, и прочие вещи.
Кстати на счет SeaWeedFS - вы писали там есть TTL, что может быть удобно в некоторых случаях. Я сделаю у себя такую поддержку.
| | |
| |
| 6.40, пох. (?), 15:45, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?
в оракловую, например. Не вижу особых проблем, кроме цены решения.
Такая картинка - отличный blob (не очень-то и 'l'), причем ее метаданные если есть - абсолютно перпендикулярны типовым для файловой системы (в последнюю очередь, полагаю, вас интересует ее atime с точностью до микросекунды), и вы их все равно в какой-то тазе банных храните ведь?
И да, орацл умеет в кластеры ;-)
btw - сколько на самом деле жрет памяти на metadata и какого объема логи на логсерверах, если не жалко?
| | |
| |
| 7.42, syslinux (ok), 16:29, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?
> И да, орацл умеет в кластеры ;-)
> btw - сколько на самом деле жрет памяти на metadata и какого
> объема логи на логсерверах, если не жалко?
В wZD? 32 байта, оно хранится прямо в файле который заливается, память не используется. Из которых 8 байт зарезервировано под будущий дистрибьютор. Логи тут не нужны.
Мне уже не нужно никакое решение, я уже все что надо сделал без любой бд.
В MooseFS на оставшиеся 10млн файлов после архивирования потребляется 8GB RAM всего с учетом директорий, а было 75GB+.
| | |
| |
| 8.44, пох. (?), 16:49, 21/01/2020 [^] [^^] [^^^] [ответить] | +/– | нет, мне было интересно именно для moose до переноса всего в архивы - чтобы пони... текст свёрнут, показать | | |
|
|
| 6.41, n80 (?), 16:22, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?
Ну, для меня решение из этой новости или всё тот же SeaWeedFS — тоже в определённом смысле СУБД. Так что база в этом смысле. Если что, я тут нигде не топил за ненужность сабжа, напротив, пишу о причинах по которым такие решения нужны и возникают.
> Кто утверждает, что такое количество допустим должно быть обязательно в фс общего
> назначения, про кластерные забыли?
Не суть, имелись в виду ФС, как бы так сказать, совместимые с POSIX-семантикой.
Которым противопоставляется специализированное решение, имеющее свои преимущества, в т.ч. за счёт отказа от всяких неиспользуемых функций.
> Вам дали способ - как упростить себе жизнь не изменяя файловую систему
> на какие-то решения, которые еще неизвестно как себя поведут (в плане фс
> изначально), в том числе оставлена без изменений работа с большими файлами,
> не надо заботится о волюмах, изменять пути в приложении, и прочие вещи.
Я же разве против? Наоборот, всецело за.
Разве что заботиться иногда всё-таки надо, это позволяет получить дополнительный выигрыш.
> Кстати на счет SeaWeedFS - вы писали там есть TTL, что может
> быть удобно в некоторых случаях. Я сделаю у себя такую поддержку.
Наверное, уточню: в моём случае протухание по TTL реализовано внешним скриптом (потому что логика выбора удаляемых файлов немного нетривиальная), который посылает пачку запросов на удаление. Залить несколько миллионов файлов, потом продолжать потихоньку заливать файлы, а потом через сутки 2% самых старых из них удалить пачкой запросов — суровый такой стресс-тест. Более-менее традиционные ФС на удалении десятков тысяч мелких файлов ооочень крепко задумываются (иногда подвешивая вообще все операции ввода-вывода, пока журнал не прокачается).
| | |
| |
| 7.43, syslinux (ok), 16:36, 21/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Принял. Спасибо за уточнение как вы делаете. Значит предусмотрю изменение TTL без перезаписи файлов. То есть не только вместе с файлом когда идет первоначальная заливка, но и потом чтобы можно было поменять TTL на другой или убрать TTL вовсе. Методом DELETE можно и внешним скриптом пользоваться как у Вас без поддержки встроенного TTL.
На счет задумываться - да ФС имеют такие проблемы при очень массовых операциях. У меня в теории не должно быть проблем, не фс все-таки, принцип то примерно тот же как в SeaWeedFS, просто если думать волюмамим, то у меня волюмов столько сколько папок по сути, в них еще быстрее удаление будет работать.
Я ни в коем случае не говорю Вам что мое чем-то лучше тоже, просто тема об одном, а уже Оракл сюда был приплетен. Да и я сомневаюсь что он нормально будет работать, там один индекс будет громадным, это надо тестировать сначала Оракл в таком ключе, а потом уже писать сюда, а то это просто предположение :)
P.S. Просмотрел, это не Вы написали про Оракл изначально, другие комментаторы молодцы.
SeaWeedFS тут совершенно корректно сравнивать, у меня решение зависимо конечно, в случае большого сторейджа, от обычных кластерных ФС на данный момент, но потом будет дистрибьютор и можно будет обходится и без кластерных ФС.
| | |
|
|
|
|
|
|
| |
| 2.27, анонн (ok), 13:48, 20/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Это для тех у кого ФС до сих пор не умеет в tail packing? :)
Наверное, это для тех, кто в курсе минимального размера фрагмента/(суб)блока и разницы между ФС и "solid archiv".
А в "tail packing" (block suballocation) умеют и древние ФС - нашли чем хвастаться :)
| | |
|
| 1.48, syslinux (ok), 07:45, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Завез я уже поддержку HTTPS, Keepalive, авторизацию per vhost, включение отключение 404-ых, метод POST(только бинарные данные так же как и в PUT), метод OPTIONS, и еще по мелочи. Пока только в ветке мастер, если кому надо можете попробовать собрать потестировать, версия 1.1.0-beta собрана на гитхабе. Это еще не все что туда будет добавлено.
| | |
| 1.51, hes (?), 17:33, 15/01/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
очень похоже на Grafana/Loki. Так же boltdb в качетсве хранения данных, только там хранят логи
| | |
|
