Небольшой релиз с исправлениями ошибок.
vitastor-cli rm с assert(rwo->todo == 1), появившееся в 3.2.1ddrm с «обратной» оптимизацией неверно удалял данные слоя перед переименованием,
что могло приводить к некорректному чтению из дочерних образов при удалении снапшота старше последнегоmerge и производных командах (rm, flatten)serve (спасибо Степану Работкину)serve из-за некорректного разбора запроса (спасибо Vincent Schweiger)serve без HTTPS (спасибо обоим :))Это корректирующий релиз, и большая часть исправлений внесена благодаря новому подходу к тестированию: хаос-тесту блочного хранилища, который теперь запускается в CI при каждом изменении.
Также спасибо Юрию Лунёву из MIND Software за другую часть исправлений.
Кроме хаос-теста и исправлений стабильности, в релиз также входит несколько новых функций:
vitastor-cli modify --resize.mount.vitastorfs и mount.vitastorblk — ФС теперь можно
монтировать из /etc/fstab.--readahead в команде монтирования: увеличение ускоряет
чтение в 2-3 раза.use_sync_send_recv) — при
включённом RDMA это ничем не хуже по производительности./healthcheck в мониторе.soft,sync.EAGAIN, OSD обрабатывают эту ошибку, а обязанность
повторить запрос возлагается на клиента. Исправление меняет логику обработки ошибок на стороне
клиента, поэтому при использовании старого хранилища рекомендуется обновить клиентов.Блочное хранилище теперь покрыто тестом в стиле DST (детерминистический симуляционный тест), управляемым сидом. Хранилище запускается в симулированной среде: io_uring отдаёт завершения не по порядку и со случайной задержкой, энергозависимый кэш диска при симулированном отключении питания теряет случайное подмножество своего содержимого, а записи, летевшие в этот момент, доезжают целиком, частично (рвутся по границе сектора) или не доезжают вовсе. Само хранилище при этом настоящее — журнал, метаданные, флашер, компактизация, контрольные суммы. Рядом ведётся модель записанных данных и после каждого отключения питания восстановленное состояние сверяется с ней, включая битмапы объектов.
Тест запускает обе реализации хранилища на одной и той же нагрузке в 24 конфигурациях: старое и
новое хранилище, серверные и десктопные диски (с конденсаторами и без), двухфазные (EC) и
мгновенные (реплицированные) записи, контрольные суммы выключены / включены с блоком 4 КБ / 16 КБ.
CI прогоняет 200 сидов на каждой сборке, по процессу на сид, и печатает список упавших сидов —
после чего любое падение можно чётко воспроизвести командой test_blockstore_chaos --seed N.
Для понимания масштаба: на хранилище из 3.1.0 текущий хаос-тест падает на 83 сидах из 200 без учёта утечек памяти и строгого запрета одновременной записи одного и того же сектора, а с их учётом - на 97 сидах из 200.
# конфигурация сломано/всего
8 v2 fsync=0 csum=16384 instant 4/9
9 v2 fsync=1 csum=none instant 1/8
10 v2 fsync=1 csum=4096 instant 1/8
12 v1 fsync=0 csum=none two-phase 8/8
13 v1 fsync=0 csum=4096 two-phase 8/8
14 v1 fsync=0 csum=16384 two-phase 8/8
15 v1 fsync=1 csum=none two-phase 8/8
16 v1 fsync=1 csum=4096 two-phase 8/8
17 v1 fsync=1 csum=16384 two-phase 8/8
18 v1 fsync=0 csum=none instant 8/8
19 v1 fsync=0 csum=4096 instant 8/8
20 v1 fsync=0 csum=16384 instant 8/8
21 v1 fsync=1 csum=none instant 1/8
22 v1 fsync=1 csum=4096 instant 3/8
23 v1 fsync=1 csum=16384 instant 8/8
Доминирующие проблемы:
BUG: Unexpected dirty_entry ... unstable state during flush — на каждом сиде всех шести двухфазных (EC) конфигураций — или отказывается
стартовать с Fatal error (bug): big_write journal_entry was allocated over another object.retval=-33), а в одном случае возвращается с данными другого объекта.Теперь же все эти проблемы исправлены.
meta_format 2, OSD, созданные до 3.0) — да, независимо от железа.
Оно падало в хаос-тесте во всех конфигурациях, включая рекомендуемые.immediate_commit=none) — да. В обоих версиях
хранилища исправлены значительные баги, связанные с SYNC, такие, как потеря подтверждённых
данных при отключении питания.csum_block_size) — да, и это касается обоих
хранилищ. Чтения частично записанных блоков могли падать с ложной ошибкой контрольной суммы на
совершенно целых данных, а у нового хранилища объект мог стать нечитаемым после отключения
питания даже на серверных SSD.Старое хранилище (meta_format 2):
inmemory_journal.inmemory_journal неизменённый журнальный сектор — или даже суперблок журнала —
мог быть перезаписан некорректными данными, после чего OSD отказался бы стартовать.Новое хранилище (meta_format 3):
immediate_commit=none) Старое хранилище:
Новое хранилище:
Только старое хранилище:
fill_partial_checksum_blocks().read_bitmap() при чтении удалённой версии объекта.assert(fulfilled == read_op->len) в dequeue_read().pg_minsize.make-etcd с IPv4 и автоопределение пула в snap-create (и то, и то сломано в 3.1.0).vitastor-dd теперь определяет seekable-ввод и вывод, включая stdin/stdout.MSG_WAITALL.meta_block_size, теперь отклоняются при
инициализации OSD, а не приводят к делению на ноль в vitastor-disk.WRITE_STABLE поверх нестабильного WRITE в старом хранилище
(неиспользуемый OSD и с неопределённым поведением).memset нулевой длины по NULL, неинициализированная память.outbox_push для уже
несуществующего клиента, некорректный начальный EPOLLIN в HTTP-клиенте.Полный лог коммитов доступен по ссылке на релиз ниже.
Наконец, релиз на тему безопасности!
Новые функции:
Читайте подробную документацию функций безопасности по ссылке: https://vitastor.io/docs/usage/security.html
Много исправлений, но мелких. :-)
Наиболее интересные исправления связаны с пулами без immediate_commit (для настольных SSD): исправлены граничные случаи операции фиксации изменений (sync) и работа CAS-записей (используемых, например, в VitastorFS).
Также исправлен баг “double-claim” в новом хранилище и внесены изменения, снижающие нагрузку на etcd во время активных переключений состояний PG.
Подробнее читайте ниже.
На этот раз исправления мелкие:
Сколько (багов!) я зарезал, сколько перерезал! (более 50)
Общее замечание: большинство исправлений ошибок теперь сопровождаются регрессионными тестами, проверяющими, что они не повторятся в будущем. Большинство ошибок, исправленных в этом релизе, было обнаружено с помощью анализа LLM (Claude Opus/Fable, GPT 5.5).
Единственное исправление:
⚠️ Внимание - если баг вас затрагивает, лучше обновляться с приостановкой i/o клиентов