«Пропавшие» кассеты: библиотека их видит, продукт считает missing

Коротко. Продукт читает штрихкод из библиотеки и отбрасывает два последних символа (000281L8 → 000281), а затем сверяет результат с реестром кассет. Если кассета заведена в реестр полной 8-значной формой, совпадений нет — и продукт считает «пропавшими» все кассеты сразу. Через decommission_after часов он снимает их с учёта сам; спасает только предохранитель по числу пропавших.

Симптом

COLD_STORAGE_TAPE_AUTODECOMMISSION_BACKOFF (ERROR) с полями missing_tapes: N и max_tape_allowed: 2, повторяется с тактом около 4 часов, occurrences растёт.
Периодически — COLD_STORAGE_TAPE_DECOMMISSIONED (INFO) с пустым barcode="".
В модели missing_tape_media есть записи с missing_since (обычно сразу после перерегистрации кассет).
Библиотека при этом отдаёт все кассеты как доступные; transportd_tape_library_media{status="OK"} равна числу кассет в библиотеке.
Если штрихкод невалиден (последние два символа не L8/L9/M8/CU), картина другая: tape_media_verify прерывается целиком с текстом Tape media with invalid barcodes found, и поднимается COLD_STORAGE_INVALID_BARCODE_DETECTED.

Расхождение — не в библиотеке. Ломается запись о кассете в продукте.

Что проверить первым (read-only)

Запросы к модели — на узле, root (сертификаты продукта root-only).

Каталог библиотеки (SWS): bash curl -sk "https://<CONNECTOR_HOST>/sws/v2/media/fsmedlist/state?format=JSON" \ | jq '[.classes[] | {classId, medias: [.available.medias[].mediaId]}]' Ожидается полная форма штрихкода (8 символов, с суффиксом поколения). Список сохранить для сверки.
Реестр продукта — на узле, от marvin: bash T=/opt/ampli/apps/foos/bin/tapecmd; CONF=$(ls /opt/ampli/cfg/foos/*.conf | head -1) $T --config $CONF media list Ожидается основа без суффикса (000281, не 000281L8). Если видна 8-значная форма — это причина.
Записи «пропавших» в модели: bash sudo curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ "https://127.0.0.1:8443/model/tapeconnector/<CONNECTOR_NAME>/" \ | jq '."tapeconnector"[] | .missing_tape_media // empty' Ожидается пусто. Если записи есть — сверить missing_since с датой регистрации кассет.
Контроль железа: $T --config $CONF drive list → приводы Ok; число кассет в реестре совпадает с библиотекой по количеству.
Форма штрихкода по правилу продукта: 6 буквенно-цифровых символов + 2 символа типа носителя, тип — только M8, CU или L[A-Z0-9]; остальное — ^[A-Z0-9]{6}$.

Причина

Продукт сопоставляет «на месте / пропала» по штрихкоду. Читая каталог библиотеки, он срезает два последних знака (комментарий в коде — «Drop LTO identifier») и сравнивает основу с реестром.

Если кассета заведена полной формой (000281L8), пары не находится ни для одной кассеты. Дальше работает таймер: по истечении decommission_after (по умолчанию 96 часов) продукт снимает кассету с учёта и обновляет событие. Предохранитель max_missing_tapes (по умолчанию 2) останавливает массовое снятие: при большем числе «пропавших» продукт только шлёт AUTODECOMMISSION_BACKOFF. Поэтому при пяти «пропавших» кассеты ещё целы — но ждать «само рассосётся» нельзя: стоит числу опуститься до двух, и снятие пойдёт.

Второй корень — записи без штрихкода. Если кассеты заводили по uuid, сопоставлять нечего, и запись «отсутствует» навсегда. В missing_tape_media при этом может лежать одна запись на несколько кассет — дедупликация по пустому штрихкоду сбивает счёт.

Чего механизм не делает: не теряет данные (кассеты на месте и защищены), не лечится перезапуском служб (реестр — данные, не рантайм) и не лечится правкой рендера foos (ближайший configure вернёт вендорские значения).

Решение (штатное)

Завести кассеты в реестр основой штрихкода (без суффикса поколения) — штатным управляющим каналом продукта (AddTapeMedium), которым пользуется коннектор. В нашей практике это скрипт-обёртка с обязательным --apply: connector_add_medium.py <BASE_BARCODE> --uuid <UUID> --apply Ожидается: tapecmd media list показывает кассету с основой штрихкода.
Снять старые uuid-записи адресно, по одной. Изменить запись нельзя: AddTapeMedium на существующий uuid отвечает FailedSequenceException. Удаление — штатными командами tapecmd, сначала статусы медиа и томов, затем освобождение поколения: tapecmd --config <CONF> media set-status --status Marked --persist tapecmd --config <CONF> volume set-status --status marked|compacted --persist tapecmd --config <CONF> media wipe-generation <UUID> --persist Ожидается: записи уходят по одной. Не применять media unused --delete --persist оптом — это сносит реестр целиком, включая живые кассеты с данными.
Дождаться цикла coldstorage.tape_media_verify (до 4 часов) либо дать продукту пройти задачи после изменения реестра; расписание при этом не меняется.
Проверить запас отдельно. «Пропавшие» и safety = 0 — разные события; после приведения формы может остаться вопрос числа кассет в группах, см. TAPE SAFETY = 0.

Если штатный путь недоступен

Не штатно, временная мера. Когда запись не снимается (команда отчитывается «removed successfully», а запись остаётся), допустимо оставить её в нейтральном статусе OK и держать предупреждение в проверке, пока реестр не закроет вендор. Пометить в реестре обходов, что записи переведены в нейтральный статус, а не удалены.

Не делать: не убирать из библиотеки кассету, заведённую в продукте («чтобы продукт забыл» — через 96 часов он снимет её сам); не гонять оптовое удаление медиа; не править рендер foos руками.

Проверка

missing_tape_media пуст либо missing_since не обновляется.
Новых AUTODECOMMISSION_BACKOFF нет за два цикла (около 8 часов).
tape_media_verify → SUCCESS; число найденных кассет и ёмкость в журнале задачи совпадают с ожидаемыми.
Число кассет в fsmedlist/state равно числу в реестре (по количеству, не по форме).
transportd_tape_library_media{status="OK"} не уменьшается.
Проверка реестра не печатает предупреждения о неверной форме штрихкода.

Профилактика

Состав кассет брать только с железа. Не «дописывать» кассеты в каталог ради закрытия пустого genscratch: панель и реестр начнут показывать кассеты, которых физически нет.
Реестр — в основной форме. Полная 8-значная форма допустима в библиотеке, но не в реестре продукта.
Проверять реестр перед каждым изменением ленты, а не после аварии.
Держать запас по схеме — Планирование холодного тира и ленты.
Читать события парой: AUTODECOMMISSION_BACKOFF — про реестр, TAPE_SAFETY_EQUALS_ZERO — про число кассет; лечатся по-разному.

Источники и дата

Quantum, ActiveScale Software Release Notes (6-68852): https://qsupport.quantum.com/kb/flare/Content/ActiveScale/PDFs/6-68852_ActiveScale_Software_Release_Notes.pdf (дата доступа: 2026-11-07).
Quantum, Software Documentation Center (ActiveScale 7.3): https://qsupport.quantum.com/kb/flare/Content/ActiveScale/Software/Content/Index_Files/Index_Software.htm (дата доступа: 2026-11-07).
Наша практика, обезличено: разбор «пропавших» кассет на стенде — реестр вёлся полной формой, продукт срезал LTO-суффикс; предохранитель 5 > 2 удержал снятие с учёта.
Обновлено: 2026-11-07.