Это копипаста с Хабра?

с доступом попротоколу

С каким, простите, доступом?..

Попопротоколу, очевидно же.

Модераторы исправьте "попротоколу"

В изначальном сообщении новости было написано правильно. Но если исправили сами, то пожалуйста исправьте уж как надо. Спасибо.

выдайте мне файл project1.vbs, от 1 января не помню какого года, пожалуйста. а то я его потерял

Давно ждал систему с доступом попротоколу!

Что-то все зациклились на «попротоколу». Дальше тоже интересно:

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

поддержка целостности данных CRC при записи/чтении;

А при попытке узнать что такое «компакция данных» у меня сломался startpage.

Не написан на Го. Не связываться от слова совсем.

Модераторы не очень хорошо переписали новость. Компакция - уменьшение архивов, если часто del или overwrite файлов делать.

А какой версии webdav держится? И кто его держит?

А как решили проблему с тем, что нжинкс грузит весь файл с оперативу, а не чанками грузит и отдает?

А метод lock webdav поддерживается? webdav_ext методы?

Модераторы не очень хорошо переписали новость. Компакция - уменьшение архивов, если часто del или overwrite файлов делать.

Все равно непонятно. Скорее всего «если часто del или overwrite файлов делать» то размер архивов (?) вырастет, а не уменьшится. Может быть, компакция, это переупаковка архивов для оптимизация размера после множества операций удаления и перезаписи файлов в этих архивах, аналог дефрагментации файловой системы, только для архива?

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

Походу lock есть.

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

Боюсь, это лютый бред.

Походу lock есть

В один архив можно только последовательно писать, это невозможно по другому. Но вот в несколько разных, запросто параллельно.

Все равно непонятно. Скорее всего «если часто del или overwrite файлов делать» то размер архивов (?) вырастет, а не уменьшится. Может быть, компакция, это переупаковка архивов для оптимизация размера после множества операций удаления и перезаписи файлов в этих архивах, аналог дефрагментации файловой системы, только для архива?

В общем так и есть.

Go 96.2%

Wut.

А какой версии webdav держится? И кто его держит?

А как решили проблему с тем, что нжинкс грузит весь файл с оперативу, а не чанками грузит и отдает?

А метод lock webdav поддерживается? webdav_ext методы?

Это пока первый релиз, сначала тестирование нужно.

Webdav в todo есть. Возможно реализуем полностью.

В nginx я ничего не делал, планируется добавить авторизацию по IP как минимум в следующий релиз wZD, и возможно другие опции для того чтобы можно было ставить без nginx/haproxy. Таймауты уже поддерживаются.

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

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

Но ведь он все равно закрыт за nginx? Иначе кто https держит? Авторизацию? И как он обходит ограничение на размер http запроса? Как грузит чанками, если клиент этого не поддерживает?

Но ведь он все равно закрыт за nginx? Иначе кто https держит? Авторизацию? И как он обходит ограничение на размер http запроса? Как грузит чанками, если клиент этого не поддерживает?

Поддержка HTTPS запланирована. Авторизация, я ответил ранее - будет сделана в следующем релизе.

Всегда возвращается Content-Length с точным размером, поэтому клиент будет ждать пока ему не придет в точности нужное количество байт(таймаут есть тоже). Не используется Transfer-Encoding: chunked.

Nginx не помещает в таком случае весь файл в оперативку. Клиенту сразу как будто потоком идут данные.

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

В том числе благодаря этому поддерживаются If-Not-Modified и другие заголовки.

Попробуйте, потестируйте для начала.

Добавлю лишь, что на самом деле wZD хорошо работает за Nginx, нигде память не потребляется при работе с большими файлами, но тем не менее свой https и своя авторизация должны быть в итоге сделаны все равно.

Когда в портах будет?

Когда в портах будет?

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

Свой репозиторий по крайней мере для пары основных линуксов будет к следующему релизу +- через месяц.

Для *BSD и редких линуксов будет инсталляционный скрипт. Имеет ли смысл делать форк портов и добавлять туда свой пакет на текущем этапе?

Я думаю примут в официальное дерево без проблем. А так хотя бы Makefile и pkg-descr.

Я думаю примут в официальное дерево без проблем. А так хотя бы Makefile и pkg-descr.

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

А при попытке узнать что такое «компакция данных» у меня сломался startpage

Да, наиболее релевантные ссылки в гугле ведут на Хабр, откуда это скопипащено и на сам ЛОР. Да и попротоколу на эту компакцию.

Так и назову потом свой нативный протокол - poproto будет poproto = true в конфиге :)

Поправил попротокол в новости ) Испоганил не я, если что :)

Благодарю :)

nginx/haproxy

А где поддержка lighttpd.
К черту идет ваш АНБшный нжыникс

отличное название, я считаю. «Отправьте ваши файлы в ЗэДэ! Там им самое место!»

А где поддержка lighttpd. К черту идет ваш АНБшный нжыникс

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

отличное название, я считаю. «Отправьте ваши файлы в ЗэДэ! Там им самое место!»

Я это знал…что понравится :)

ты сам что ли это смастерил? для чукчи, кто не читатель или устал под конец дня, можно коротко, что ты допиливал (что используется, кроме общедоступных компонентов типа nginx) в этом проекте.

ты сам что ли это смастерил? для чукчи, кто не читатель или устал под конец дня, можно коротко, что ты допиливал (что используется, кроме общедоступных компонентов типа nginx) в этом проекте.

Да, сам смастерил. Сам bolt допиливал, чтобы из значения(файла) можно было получать столько байт сколько надо, не дергая диск на чтение всего значения, для методов типа HEAD или заголовков Range: bytes=… Да вся инфа на гитхабе есть, че сюда это тянуть.

Остальное не сильно значимо, я так думаю.

это новый картинко хранилка?

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

Не рекомендуется загружать в Bolt архивы файлы или значения размером больше 16МБ.

в контексте «поддерживается работа с большими файлами без ущерба производительности».

Для меня «большие» файлы это все-таки 1 тб и далее.

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

можно было получать столько байт сколько надо

а еще раз для чукч, что у нас за юзкейс, когда пользователю нужна только часть?

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

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

еще раз для чукч, что у нас за юзкейс, когда пользователю нужна только часть?

Докачка (Accept-Ranges), метод HEAD. Вы скачиваете файл, поставили на паузу, затем продолжили(новый запрос к серверу)

У Вас как думаете плеер на ютубе работает? Там сплошной Range: bytes=… браузер просит с такого по такой диапазон. Перемотка.

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

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

Для меня «большие» файлы это все-таки 1 тб и далее.

Почитайте внимательнее на странице проекта - там есть документация на русском.

Большие файлы записываются и читаются как обычные файлы. Они не попадают в архивы, в этом нет смысла. В этом и дело почему мое решение лучше объектных хранилищ, у меня сервак одинаково хорошо работает как с мелочью, так и с большими файлами при таком подходе. Пакуется только мелочь, вот и не рекомендуется именно паковать файлы больше 16МБ, потому что чем больше файл, тем выгоднее его положить как обычный файл, а не в болт архив.

Лейте на здоровье 1TB, он рядом ляжет, а не в архив :)

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

Вы zip архив видели? Если да, тоже самое, только без недостатков в плане работы с данными прозрачно напрямую в bolt архиве, вплоть до возможности читать диапазоны из каждого файла в архиве.

В том числе это надо чтобы не терять место, особенно в кластерных ФС где минимальный блок бывает и 64KB, залили 100 * 1KB файлов, а на самом деле потратилось 100 * 64KB.

В тестах идут запросы к разным файлам или много запросов к одному? Тема фс кеша не раскрыта.

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

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

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

Поддержка HTTPS запланирована. Авторизация, я ответил ранее - будет сделана в следующем релизе.

На мой взгляд, если уж сверху ставите nginx, то это лишнее. А какой может быть https на внутреннем приватном адресе и без доменного имени и вовсе непонятно.

Всегда возвращается Content-Length с точным размером, поэтому клиент будет ждать пока ему не придет в точности нужное количество байт(таймаут есть тоже). Не используется Transfer-Encoding: chunked.

Гораздо больше волнует put, а не get. Отдаать большие файлы умеют все, а вот что с их отправкой на сервер?

Вот это разве гут? А приходится, когда вебдав за нжинксом.

 client_max_body_size 4G;

Nginx не помещает в таком случае весь файл в оперативку. Клиенту сразу как будто потоком идут данные.

Насколько я помню, коммунити нжинкс скидывает данные в темповый файл и потом отдает его на бекэнд, что дает по сути двойное время реакции. Отдавать передаваемые данные (почти) сразу умеет платная версия nginx или tengine.

аж воротит от твоих букв без пунктуации

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

Компакция - уменьшение архивов, если часто del или overwrite файлов делать. - русского термина не нашлось у попугаев?

Насколько я помню, коммунити нжинкс скидывает данные в темповый файл и потом отдает его на бекэнд, что дает по сути двойное время реакции. Отдавать передаваемые данные (почти) сразу умеет платная версия nginx или tengine.

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

Да, если лить напрямую в wZD сервер, то запись будет через малые буферы на лету проводится без временных файлов, как возможно и в платной версии nginx plus, у меня ее нет, не проверял.

В том числе для того, чтобы избежать буферизации на реверс прокси, у меня будет сделана полноценная поддержка того же HTTPS. Хотя в реальной жизно обычно делают так - для GET запросов снаружи ставят реверс прокси, а заливают большие файлы напрямую, даже через HTTP без HTTPS.

аж воротит от твоих букв без пунктуации

Значит я делаю все правильно :) Критика это хорошо, мне любая критика нравится.

Вы бы сначала создали например язык программирования в котором можно было бы весь код полностью писать на русском, чтобы там были все библиотеки нужные и тп. А то я смотрю английские заимствования слов не нравятся. 1с не предлагать.

Например слово компьютер - не наше, но все им пользуются :). Как в библиотеке болта было написано - compaction - так я и оставил.

свой https и своя авторизация должны быть в итоге сделаны все равно

А как же KISS?

Не жужжи. Я вообще название для своей поделки выбрал — «monda». Релизну — оборжотесь.