URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 86687
[ Назад ]

Исходное сообщение
"Битые ленты или неверный размер блока на экзабайте?"
Отправлено Im27th , 23-Сен-09 16:58

Подняли старый архив с целью переписать его на LTO.
Естественно никто не помнит ни кто писал ни как писал эти ленты. А происходит с ними следующее:
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
   file no= 0   block no= 0
пытаемся копировать
# tcopy /dev/rmt/9n test1
file 1: record 1: size 2696
file 1: records 2 to 579: size 10056
file 1: eof after 579 records: 5815064 bytes
Write EOF: Inappropriate ioctl for device
не пойму - лента битая или размер блока не нравится?
но вперёд продвинулись:
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x12)= EOF   residual= 0   retries= 0
   file no= 1   block no= 0
но потом уже ничего скопировать нельзя
# tcopy /dev/rmt/9n test2
file 1: eof after 0 records: 0 bytes
Write EOF: Inappropriate ioctl for device
и tarом тоже не копируется:
# tar xvf /dev/rmt/9n
tar: tape read error
# tar xvf /dev/rmt/9n test3
tar: tape read error
либо
# tar xvf /dev/rmt/9n
tar: blocksize = 0
перемотки работают, но не все:
# mt -f /dev/rmt/9n fsf 2
сработало
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
   file no= 3   block no= 0
# mt -f /dev/rmt/9n eof
сработало
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
   file no= 4   block no= 0
но и fsf не всегда срабатывает:
# mt -f /dev/rmt/9n fsf 5
/dev/rmt/9n fsf 5 failed: I/O error
не сработало
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x8)= Blank Check   residual= 0   retries= 0
   file no= 4   block no= 0
и когда fsf не срабатывает, у него sense key не 0x0, а то 0x8, то 0x13
а bsf вообще всегда скидывает на начало ленты
# mt -f /dev/rmt/9n bsf 4
/dev/rmt/9n bsf 4 failed: I/O error
не сработало
# mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x15)= BOT   residual= 0   retries= 0
   file no= 0   block no= 0
# dd if=/dev/rmt/9n of=/mnt/test bs=60k count=1
0+0 records in
0+0 records out
#  mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x12)= EOF   residual= 0   retries= 0
   file no= 0   block no= 0
и ещё в /usr/local/bin/ нет ioctl
я просто думал, что может он прояснит ситуацию с блоками?
хотя никогда с ним не сталкивался, только сейчас пытаюсь понять что же это такое?
если что:
# uname -a
SunOS blade 5.8 Generic_117350-18 sun4u sparc SUNW,Sun-Blade-1000

Содержание

Битые ленты или неверный размер блока на экзабайте?,Im27th, 10:58 , 24-Сен-09
- Битые ленты или неверный размер блока на экзабайте?,Im27th, 09:56 , 25-Сен-09
  - Битые ленты или неверный размер блока на экзабайте?,Im27th, 14:49 , 01-Окт-09
    - Битые ленты или неверный размер блока на экзабайте?,goblin13, 13:28 , 01-Дек-09

Сообщения в этом обсуждении

"Битые ленты или неверный размер блока на экзабайте?"
Отправлено Im27th , 24-Сен-09 10:58

Ничего не пойму.
Может само устройство нагнулось?
Есть какие-то средства протестировать?
# tar tvf /dev/rmt/9n
tar: tape read error
# tar xvfb - 512k /dev/rmt/9n test4
зависает при любом размере блока - всякие перепробовал
# pax -l -f /dev/rmt/9n
pax: No input
# cpio -civt < /dev/rmt/9n
End of medium on "input".
To continue, type device/file name when ready.
Уже и не знаю, что ещё попробовать.

"Битые ленты или неверный размер блока на экзабайте?"
Отправлено Im27th , 25-Сен-09 09:56

В общем устройство рабочее.
Ленточки, на которые что-то писалось tarом - читаются.
А на эти ленты, которые я не могу прочитать, оказывается записаны сейсмические файлы в некоемом формате SEG-D
http://74.125.77.132/search?q=cache:o9V6GANBKcMJ:www.seg.org...
Прочитал несколько статей про этот формат, но не узрел информации, которая могла бы меня спасти.
Дело в том, что до этого всегда с этих ленточек загоняли данные сразу в специальную сейсмическую программу ProMAX - она эти ленты читает легко, но она данные сразу при считывании конвертирует в другой сейсмический формат seg-y.
А так как сейчас идёт просто перевод архивов со старых лент на новые, то формат необходимо оставить seg-d.
В общем появилось ещё 2 мысли:
1. Слышал, что во времена бобин была какая-то утилита, которая тупо прокручивала всю ленту и выдавала информацию о количестве файлов, размерах блоков, метках, концах и началах файлов.
Есть ли что-то подобное сейчас под Solaris 8?
2. Может быть есть какая-то утилита, которая будет тупо считывать всё в один большой файл, не взирая на метки и концы и начала файлов? Всё равно cейсмики потом для работы все эти мелкие файлы сгоняют в один.

"Битые ленты или неверный размер блока на экзабайте?"
Отправлено Im27th , 01-Окт-09 14:49

В общем нашёл в интернете утилиту segd2disk
Но и оно не помогло.
Тут я всё-таки заподозрил ленты в убитости и пришлось перебрать большую кучу лент, чтобы найти таки рабочую, либо всё же записанную как-то по-другому. Хотя и в ней идёт два EOF подряд, а как их обходить я так и не понял. Ну ясно дело, что я написал скрипт, который сам запускает копирование следующего файла, но думаю, что есть стандартные методы.
prouser(blade)/bigsan4/A>touch test1
prouser(blade)/bigsan4/A>tcopy /dev/rmt/9n test1
file 1: record 1: size 2656
file 1: records 2 to 515: size 10056
file 1: eof after 515 records: 5171440 bytes
Write EOF: Inappropriate ioctl for device
prouser(blade)/bigsan4/A>mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x12)= EOF   residual= 0   retries= 0
   file no= 1   block no= 0
prouser(blade)/bigsan4/A>touch test2
prouser(blade)/bigsan4/A>tcopy /dev/rmt/9n test2
file 1: record 1: size 2656
file 1: records 2 to 515: size 10056
file 1: eof after 515 records: 5171440 bytes
Write EOF: Inappropriate ioctl for device
prouser(blade)/bigsan4/A>mt -f /dev/rmt/9n status
Exabyte EXB-8500 8mm Helical Scan tape drive:
   sense key(0x12)= EOF   residual= 0   retries= 0
   file no= 2   block no= 0
prouser(blade)/bigsan4/A>touch test3
prouser(blade)/bigsan4/A>tcopy /dev/rmt/9n test3
file 1: record 1: size 2656
file 1: records 2 to 515: size 10056
file 1: eof after 515 records: 5171440 bytes
Write EOF: Inappropriate ioctl for device
prouser(blade)/bigsan4/A>ls -al
total 31648
drwxrwxrwx   3 99       99          4096 Sep 30 06:58 .
drwxrwxrwx 153 root     root       12288 Sep 29 05:38 ..
-rwxrwxrwx   1 prouser  prouser   619624 Sep 30 04:12 segd2disk
-rw-r--r--   1 prouser  prouser  5171440 Sep 30 06:46 test1
-rw-r--r--   1 prouser  prouser  5171440 Sep 30 06:57 test2
-rw-r--r--   1 prouser  prouser  5171440 Sep 30 06:58 test3
А утилита segd2disk пишет один файл 1.sgd и останавливается, думая, что лента кончилась и тоже выдаёт какую-то ошибку (об этом я обнаглев написал разработчикам этой утилиты):
prouser(blade)/bigsan4/A>segd2disk /dev/rmt/9n /bigsan4/A
***  ERROR  ***  Disk file write error on unit 8, status = -1
wrdisc: Invalid argument
Запуская её второй раз она пишет второй файл, но перезаписывая файл 1.sgd, поэтому приходится его перед этим переименовывать.
В общем проблема оказалась в битости лент. Но данные с них всё равно нужны, так что возращаюсь к ним.
А есть для лент что-то типа scandisk или fsck?

"Битые ленты или неверный размер блока на экзабайте?"
Отправлено goblin13 , 01-Дек-09 13:28

>В общем нашёл в интернете утилиту segd2disk
размер блока
tcopy /dev/rmt0
посмотри потом попробуй с -s maxblk