Теперь у нас есть ответ на вопрос — можно ли из говна и палок на хаскелле сделать приемлемое хранилище и что получится. Ну вот примерно что.

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

Товарищ в соседнем чате делает статически слинкованный дистрибутив stal/ix и призывает им пользоваться. Но какую пользовательскую проблему решает статическая линковка? Эстетика — да, допустим. Но для десктопа оно еще не готово, нужен проприетарный софт, который тащит всякое динамически слинкованное. А для серверных контейнеров у меня colmena + nix которые в общем дают способ описать сервер. и я бы хотел язык получше, чем nix. но важна ли мне статическая линковка? честно говоря эстетика серверных контейнеров меня как-то крайне мало волнует, а so-хелла в никсе нет, ценой токсичности пакетного менеджера. Но опять же, на неё для серверных контейнеров мне всё равно...

Зачем в туннелях типа hysteria2 подключение сертификатов от "авторити" типа lets encrypt? Что бы они ... что? А то — что? Какой-то абсурд.

shadowsocks-то всё. причем хитро — curl всякий через него работает, а браузеры — обламываются. причем почему-то не с любых ip. с некоторых еще работает.

Думаю над миграцией со старого сторейджа (simple) на новый (ncq). ncq - от n-way cuckoo hash, это lsm сегменты + ncq индексы + один "текущий" индекс, т.к. часто hbs2-peer ничего не пишет или пишет очень мало, мне не захотелось плодить много мелких сегментов. короче что-то среднее между bitcask (не знаю что это, нейросети рассказали) и обычными LSM БД.

Варианты — миграция при старте (пир не запустится, пока не смигрирует), прозрачный сторейдж (постепенно в фоновом режиме мигрирует сам), полностью ручная миграция + ручное переключение сторейджа.

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

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

В общем, пока думаю. Работает всё вроде ок. Единственное что, текущий алгоритм мержа тяготеет к сливанию всего в один большой fossil- файл, который чем дальше тем дольше будет мержиться. Если он подойдет к терабайту — станет совсем грустно.

Надо будет как-то придумать, что бы fossil сегменты не росли больше некоего верхнего предела, но тогда мерж (удаление удалённых и томбов и старых версий) — перестаёт быть простым. Пожалуй, это следует решить ASAP. Правда не знаю как пока что.

Новости сторейджа — сделал linear scan compaсtion (не знаю это существующий термин или нет). Суть такова, что идем от более новых записей к более старым, если томб или ref - то запоминаем и последний и на дальнейшем пути выпиливаем всё с таким же ключом, но более старым таймстемпом. Из минусов — не делаем дедуп как таковой, но при нормальной работе никаких дупов быть и не должно, dup = какая-то ошибка. Может работать инкрементально — т.е задавать глубину скана и количество томбов, дальше которого не ходить.

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

При миграции большого хранилища NCQ нажрался памяти и издох несколько раз. Сколько-то блоков потерялись по дороге из-за этого, но когда пир поднялся - засинкались из сети. Ну, проблему нашёл, вставлю контроль очереди и блокировки при переполнении. Так то почти норм

У Mac OS X всё не как у людей, конечно же. Впрочем, с минимальными патчами новый сторейдж завёлся.

А вот миграция не дорабатывает и как вы думаете почему? А потому, что case insensitive filesystem.

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

А вот при миграции блоков оно и выстрелило, часть не смогло смигрировать.

Хорошая новость в том, что новому сторейджу регистр названия файлов не важен. Т.е по факту на Mac OS X можно работать только с NCQ, нет пути назад.

Интересно, почему работал git? А потому, очевидно, что что там base16 кодировка хэшей.

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

Ведь в принципе, кому в голову могло прийти делать case insensitive файловую систему и самое главное — зачем?

Только MS и Apple, только кажется, что у MS это давно в прошлом.

Что происходит с системой, если заменить сторейдж на более быстрый (по всем тестам)? Правильно, производительность падает. Пока непонятно, дело в сторейдже или недавних изменениях в TCP, остановивших жор памяти. Так что никакой микропенсии, опять обложиться тестами. Знал бы кто, какой же геморрой профилировать p2p систему. Разработка тестового сетапа для неё это сам по себе процесс сопоставимый с разработкой системы. Короче, 0.25.2 пока не рекомендую, недельку полечу нервы и навалюсь на профилирование. Заработает, куда денется.

Tуннель через ssh не работает больше. При том, что сам ssh работает. Как будто бы форсят переключение на hysteria. Hysteria работает хорошо. Пока не очень понимаю, как это возможно, но факт, уже несколько дней продолжается.

На всякий случай вновь прибывшим сообщаю, что многие недостатки гита, озвученные в треде откуда вы прибыли — решены в hbs2-git. И версионируемость ссылок, и их крипто-пруфы, и хранение прочих объектов (issues), и p2p репликация, и наличие репозитория как сущности с криптоподтверждением владения.

По поводу gitless подхода. Допустим, мы сделаем дамп каталога, где наапротив каждого имени файла будет его хэш, запишем так же ссылку на предыдущий такой файл, сам по себе файл тоже где-то сохраним и будем ссылаться на него по хэшу, а если он большой — то относительно него можем писать только файлы, в которых есть некие изменения - добавлено/удалено. Можно ли поверх такого построить систему управления исходниками и какого размера проекты она потянет? Нужны ли нам коммиты или просто аннотацию писать в тот же файл ( напомню, что коммит в гите — это текст + ссылка на парента (или двух, если это мерж + ссылка на tree - которое — просто дерево проекта ). Структура данных максимально простая — текстовый манифест. Насколько хорошо это будет работать ? А хрен его знает. Но проще не придумать, кажется.

По итогам ненужной дискуссии (надо как-то научиться избегать) решил померять скорость импорта гита vs fossil (который бд объектов держит в sqlite). Мне это интересно потому, что я как раз отказываюсь везде от sqlite в пользу lsm-подобных дисковых структур. На linux стало понятно, что fossil не закончит примерно никогда, посмотрим на openwrt - пожатый git 740mb.

Думаю, он там еще и не пакует, посмотрим на размер БД потом. Ну, гит справился за 1m12

time git --git-dir ../openwrt/.git fast-export --all   --reencode=no --signed-tags=strip | git fast-import
real  1m12.285s

fossil:

time git --git-dir ../openwrt/.git fast-export --all   --reencode=no --signed-tags=strip  | fossil import --git  ./trunk
34 минуты

Неожиданное: в fossil есть дельта и итоговый размер репо в два раза меньше гита.

А ведь хорошо учёным, наверное: если вовлёкся в дискуссию с чувачком, который в теме знает только то, что только что загуглил — то в какой-то момент просто просишь выложить индекс Хирша на стол и линейкой меряете. Самое интересное, что технически у меня возможно и есть этот самый индекс Хирша - стою соавтром нескольких бумаг, и там в сетях мне долгое время шли уведомления, что их кто-то где-то цитирует. Правда, чувствую, короткий индекс Хирша. Но может быть, больше нуля всё равно. Оставаться в академии, что бы иметь козырь для срачей в телеге — хм, заманчиво!

Собрался в Бишкек, а в Бишкеке блэкауты. Зачем лучший интернет-банк в СНГ, если у него отключили электричество?

Импорт openwrt из git в pijul идёт шесть часов, волнуюсь (git -> git - примерно одна минута)

Почему вот нет lsm-подобной файловой системы? Максимально иммутабельной, что бы каждое изменение просто меняло бы указатель на стейт, а физически бы переписывало блоки только если закончилось место ну или достигнут некий трешхолд. Окей, кажется невозможно инкрементально обновлять индексы в таком виде. Но ведь есть append-only btree — почему-то очень непопулярный. Короче, можно ж было бы встроить time machine в файловую систему почти бесплатно, кажется, что она там нужна.

(Это я случайно снёс .git в проекте)

Для нашей специальной олимпиады — вот параметры проектов. Глубина важна, т.к для каждого измененного объекта — меняются все деревья, куда он входит. Количество каталогов важно, т.к. влияет на обход в ширину.

Как мы видим, nixpkgs не сильно-то страшнее linux, примерно одного порядка явление.

Всё это, конечно, немонорепы. Монорепа — это когда тащится транзитивно весь мир, например если контора делает прошивки для роутеров на основе nix и linux — то туда приедет и nixpkgs и linux и чёрт в ступе (вместе со всей историей, которая может и не нужна)

Довольно занятно, что наличие распределенного гита приводит к тому, что в реальной распределенной разработке git как-то особо не нужен. То есть предпочитаемый способ получения изменений — получение оформленного патча как отдельного артефакта; сам "канал" с проектом как-то не особо нужен. Похоже (точно я не знаю) что в таком стиле работает и сам linux - только не через hbs2 артефакты передаются, а через почту + обвязку в b4. В таком стиле в git не хватает сохранения авторства патчей - т.е вот мержишь ты его — если сразу не заскочил — то приходится руками что-то покурочить, а это меняет хэши. А от удаления авторства страдает социальный аспект этой всей движухи.

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

То есть другими словами: репозиторий не нужен!