The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Битые ленты или неверный размер блока на экзабайте?, !*! 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

[i]пытаемся копировать[/i]

# 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

[i]не пойму - лента битая или размер блока не нравится?
но вперёд продвинулись:[/i]

# 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

[i]но потом уже ничего скопировать нельзя[/i]

# tcopy /dev/rmt/9n test2
file 1: eof after 0 records: 0 bytes
Write EOF: Inappropriate ioctl for device

[i]и tarом тоже не копируется:[/i]

# tar xvf /dev/rmt/9n
tar: tape read error
# tar xvf /dev/rmt/9n test3
tar: tape read error
[i]либо[/i]
# tar xvf /dev/rmt/9n
tar: blocksize = 0

[i]перемотки работают, но не все:[/i]

# mt -f /dev/rmt/9n fsf 2
[i]сработало[/i]
# 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
[i]сработало[/i]
# 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
[i]но и fsf не всегда срабатывает:[/i]
# mt -f /dev/rmt/9n fsf 5
/dev/rmt/9n fsf 5 failed: I/O error
[i]не сработало[/i]
# 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

[i]и когда fsf не срабатывает, у него sense key не 0x0, а то 0x8, то 0x13
а bsf вообще всегда скидывает на начало ленты[/i]

# mt -f /dev/rmt/9n bsf 4
/dev/rmt/9n bsf 4 failed: I/O error
[i]не сработало[/i]
# 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 (1)
    Ничего не пойму.
    Может само устройство нагнулось?
    Есть какие-то средства протестировать?

    # tar tvf /dev/rmt/9n
    tar: tape read error

    # tar xvfb - 512k /dev/rmt/9n test4
    [i]зависает при любом размере блока - всякие перепробовал[/i]

    # 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, 09:56 , 25-Сен-09 (2)
      В общем устройство рабочее.
      Ленточки, на которые что-то писалось 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, 14:49 , 01-Окт-09 (3)
        В общем нашёл в интернете утилиту 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 и останавливается, думая, что лента кончилась и тоже выдаёт какую-то ошибку [i](об этом я обнаглев написал разработчикам этой утилиты)[/i]:

        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?




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру