Задачка.

Имеем бэкап 11.50.FC8W2 сделаный путём

ontape -s -L 0 -t STDIO | /usr/local/bin/pbzip2 -l >file


Всегда так делаем. И проверочные восстановления показывают что он хорош.

Хотим сделать два дела сразу - проверить восстановление и проверить производительность нового RAID (ну вот тест такой странный)

Запускаем

bzcat file | ontape -p -t STDIO -v


Имеем

03/14/14 19:32:41 The external backup for the root chunk (chunk number 1) is not valid.
03/14/14 19:32:42 IBM Informix Dynamic Server Stopped.


Спашивается

- WTF !???

- что делать ???

(варианты на тему "битый бэкап" не предлагать, варианты "в сапорт" - тоже)

(отгадка, точнее то что помогло, существует и СУБД успешно стартовала)

не может :)

ругань была бы совсем другая

Я вас так и понял как вы задумали - проблемы с именами на диске.

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

ontape штука штатная (но тоже есть момент блокировки - слова BLOCKED: ARCHIVE в выводе "onstat -" ) для бэкапов силами СУБД.

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

Архив о котором речь в задачке сделан ontape.

vvt1так собственно в чем фокус-то?
Уже любопытства ради.

Фокус в задержке

(sleep 30; bzcat file ) | ontape -p -t STDIO -v


В тех случаях когда не работает по нормальному помогает на 100%

(упреждая вопрос - файл бэкапа на локальной ФС)

Это всё ответ "что делать".

А вот в ответе на вопрос "WTF ?" можете выпустить фантазию на волю.

Лично у меня есть три версии.

vvt1Получается, что bzip (bzcat) не успевает передать порцию данных на STDOUT и ontape ловит "мусор" или ничего не ловит в течении какого-то периода времени, что ошибочно считает ошибкой ленты и вываливается?

sleep отодвигает запуск bzcat - это ещё больше усугубит тот вариант событий, что вы описали :)

vvt1Хотя...
Если посмотреть на работу STDIN/STDOUT, то по-идее bzcat должен заполнить буфер и ждать его освобождения. А освободить буфер может только ontape считав его. Т.е. в данном случае sleep не должен бы играть ни какой роли.
Странно.

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

Но факт есть - sleep как-то помогает взлететь ontape без имения проблем со stdin

Буде ещё случай - попробую найти минимальный sleep

АнатоЛойЯковлев Павел, колИтесь. У нас всё равно мотива нет :). А я так и быть, не выдержу первым :).
Самое обидное: проблемы с восстановлением ещё были понятны, когда на 7.31 организовывали автоматическое восстановление через fifo, но тут, при явном декларировании "используйте STDIO" от разработчика...

Я колоться как-то не хочу - мне и целенькому не плохо :)

И собственно каких вы откровений-то хотите ?

Солюшен выдан. Сам в прошлом несколько раз "браковал" свежий бэкап и брал более страрый+много логов. А тут что-то торкнуло и сопоставив некоторые догадки вставил sleep - оно возьми и помоги.

И тогда поиск в Сети ничего не давал. Теперь, надеюсь, запись проиндесируется и поможет хоть кому-то в будущем.

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

vvt1а ontape при работе с STDIN он делает интерактивные запросы как при классическом восстановлении?



не делает - ему явно указан файл (то что он stdin это уже дело десятое)

и про логи не спрашивает потому что -p