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 не хватает сохранения авторства патчей - т.е вот мержишь ты его — если сразу не заскочил — то приходится руками что-то покурочить, а это меняет хэши. А от удаления авторства страдает социальный аспект этой всей движухи.

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

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

Плохая новость — в NCQ и правда есть затык скорости записи с ростом числа потоков. Хорошая новость — он обнаружен, повторяем и вроде понятно, как от него избавляться

Разбор полётов по текущему NCQ (lsm подобное хранилище с быстрой записью и дисковой хэштаблицей в качестве индекса).

Как обычно — переусложнил из-за непроверенных предпосылок, а проверить их трудно, пока не сделал.

Итого: писать в N потоков может быть до какого-то момента быстрее. Многопоточная запись на диск оправдана. Текущий дизайн этого не позволит.

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

Решение с current.data + current.size исходило из того, что писать лучше в один поток + не стоит создавать мелких файлов, лучше делать из покрупнее, а merge сразу не было (а в итоге он есть всё равно и его наличие делает current.data ненужным)

Решение трекать состояния (в памяти, записан в файл, fsync-нут) с заменой ASAP записанной строки на смещение в файле — нну, в принципе смысл есть однако получилось слишком сложно; думаю надо просто индексировать ASAP и заменять только проиндексированное.

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

Вообще говоря, имело смысл, но вот что в итоге будет по футпринту если упростить и если не упрощать — надо смотреть. Но похоже, можно просто делать сегменты достаточно маленькими (64...256 мегабайт) и лучше почаще мержить.

Все файловые операции должны быть операциями над каталогом хранилища и ничего не удалять сами и не требовать стейта: merge/index/compact — только создают новые файлы, а что делать со старыми решает верхний уровень (swap+rm или rm — в зависимости от того, мы онлайн или оффлайн).

Вместо файла current.size пишем заголовки транзакций = fsync. Да, write amplification будет — но их можно удалять при compact/merge, имеет значение только последний заголовок; в случае, если его не нашли — можно сканировать файл хоть с начала хоть с конца в поисках последнего корректного заголовка.

Все структуры будут сведены к memtable Vector (TVar HashMap ...) - хорошо масштабируется по потокам (вернее сказать, просто TVar HashMap не масштабируется)

writeQueue и trackedFiles :: TVar (HashSet FileKey)

в общем, за счёт этого всего ожидаю уменьшения кодовой базы строк на 500 и NCQ2 сравняется с SimpleStorage.

Как всегда, сначала приходит в голову более сложное решение, за исключением memtable. Думал, что сделаю попроще, без fanout этого вот. В итоге попроще тут — гарантированно затыкается — а переделать сложно; Надо как-то запомнить это и больше никогда так не делать; когда много потоков пишут — TVar HashMap considered harmful.

почти (или не почти?) любая структура данных изоморфна списку с тегами; т.е примерно suckless минус сахар

data Syntax c
  = List    (Context c) [Syntax c]
  | Symbol  (Context c) Id
  | Literal (Context c) Literal
  | OpaqueValue Opaque
  deriving stock (Generic,Typeable)

... ну только выкинуть ненужное.

К чему это я? А ну вот — я теперь понимаю, почему solana появился бинарный формат borsсh вместо cbor. Потому что комитет, которому нужно оправдывать свое существование по типу данных "borsch" невозможен. Что бы еще больше подстраховаться, можно назвать как-то еще более антикомитетно, например — jopa или похуже.

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