SUN Sparcstation 20 - вопросы

DEC Alpha, ARM, MIPS, PowerPC, SPARC, VAX, PDP-8 и другие устройства
Arix
Advanced Member
Сообщения: 2384
Зарегистрирован: 18.07.2015,08:56
Откуда: Саратов

SUN Sparcstation 20 - вопросы

Сообщение Arix » 14.03.2020,17:45

Процесс завершился. Мимо! Это был диск с NeXTSTEP. Размер файла в архиве - 2,1 Гб. Сам архив - 1 Гб.

Как в NeXTSTEP перейти в другое окно программы? Мышь опять отказала, и почему-то активизировалось другое окно. Надо вернуться в окно терминала. Alt+TAB не работает.
hcn писал(а): 14.03.2020,17:30sd0h
Пишет, что нет такого диска. Только sd0a - не ругается, но и ничего не происходит.

rsd1а - пошёл процесс. Но это опять не то. Оказалось, что очень просто понять, какой диск читается - по миганию лампочки на нём. rsd0h - замигал диск с Солярой. Теперь надо непрерывно молиться. :)
Молитвы не помогли. На 80 Мб процесс застопорился.
Идёт вторая попытка.

То, что уже скопировалось, sd0a - действительно диск NeXTSTEP. Я извлёк файл из архива, просмотрел его по F3 в файловых менеджерах, там есть имена файлов и папок, которые были на данном диске и только там.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 14.03.2020,21:05

У меня дампы чужих дисков с Solaris, Linux, NetBSD успешно сливаются по (r)sdXh, и размер дампа всегда совпадает с размером диска. По переключениям без мыши не подскажу, так как сижу в эмуляторе, только уже i386, уж очень m68k нетороплив. Кстати, надо будет будет измерить, какие под ним потери по сравнению хостом. В qemu-sparc, к примеру, int код (p7zip, openssl) проседает в 10-20 раз, float (mpg123) примерно в 100.
Попробовал собрать lz4 / lzop / zstd - лыжи пока не едут.

Arix
Advanced Member
Сообщения: 2384
Зарегистрирован: 18.07.2015,08:56
Откуда: Саратов

SUN Sparcstation 20 - вопросы

Сообщение Arix » 14.03.2020,21:36

hcn писал(а): 14.03.2020,21:05 У меня дампы чужих дисков с Solaris, Linux, NetBSD успешно сливаются по (r)sdXh
У меня сейчас так и получается. Уже третья попытка. Вторая - 680 Мб. Сейчас уже прошло 740. Если бы было можно возобновлять передачу с того места, где она оборвалась... Тут мне было бы лучше копировать не весь физический диск, а один раздел. Второй раздел - домашняя папка, её можно просто скопировать пофайлово.
Но rsd0a не передаётся, процесс не идёт.

Ну вот, опять приехали. 807 Мб, диск застучал, и процесс встал.

В мыши я, вроде, локализовал неисправность. Там подходят три провода, они вставлены в "закусывающие" клеммы. Как мне показалось, одна такая клемма разболталась, т.к. при нажатии на неё мышь начинает работать. Пропаял, стало намного лучше, но всё равно мышь подглючивает.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 14.03.2020,22:59

Arix писал(а): 14.03.2020,21:36 Если бы было можно возобновлять передачу с того места, где она оборвалась...
Это можно. На Ubuntu разжимаете gunzipом принятый дамп, допустим, выйдет 807 с чем-то мегабайт.
С этого места или лучше чуть раньше можно сделать dd skip на NeXTSTEP:
dd if=/dev/rsd0h bs=1048576 skip=806 | gzip -1 | nc -l -p 1234
На Ubuntu каждый раз пишите новый дамп в несжатом виде:
nc 192.168.1.77 1234 | zcat > dump806
При обрыве окугляете вниз размер нового дампа в мегабайтах и прибавляете 806, чтобы навести очередной dd в правильное место. В конце слкеивате куски, предварительно их подрезав (для надежности, можно подрезать копии). Если все правильно, бывший sd0a смонитруется без ошибок, примерно так: mount -o loop,ro,ufstype=sun -t ufs bigdump /mnt/tmp. Для проверки sd0b уже нужен losetup.
Еще можно передавать куски фискированого размера - тогда добавьте для dd параметр count=X, кроме того, можно отказаться от сжатия, раз оно медленное. Можно сбрасывать куски на раздел NeXTSTEP и заливать их на FTP сервер. В общем, есть варианты.
Arix писал(а): 14.03.2020,21:36 Тут мне было бы лучше копировать не весь физический диск, а один раздел. Второй раздел - домашняя папка, её можно просто скопировать пофайлово.
Но rsd0a не передаётся, процесс не идёт.
С большой вероятностью первый раздел идет с самого начала диска, и сливать весь диск необязательно, но чтобы слить второй раздел пофайлово, вам придется как-то его смонтировать. С live CD, очевидно, который понимает disklabel и ufs Соляры, то есть нужны те же Solaris или Linux. Вот NeXTSTEP даже disklabel не понимает, поэтому разделы sd0a и sd0b для него не существуют.

Arix
Advanced Member
Сообщения: 2384
Зарегистрирован: 18.07.2015,08:56
Откуда: Саратов

SUN Sparcstation 20 - вопросы

Сообщение Arix » 15.03.2020,09:24

Без сжатия скорость 800 кб/с
hcn писал(а): 14.03.2020,22:59 тогда добавьте для dd параметр count=X
X - в каких единицах? Я хочу по гигабайту, написал 1073741820.

Оказывается, в мегабайтах.
hcn писал(а): 14.03.2020,22:59 предварительно их подрезав
Как?
hcn писал(а): 14.03.2020,22:59 На Ubuntu разжимаете gunzipом принятый дамп,
Незавершенный архив не распаковывается. В процессе распаковки файл появляется, потом - gzip: disk001.gz: unexpected end of file, и файл удаляется. Если только как-то ловить его до вывода сообщения об ошибке. Помню, в винде я так делал, прибивал Винрар, когда он выдавал сообщение о неожиданном конце архива. Но там, пока висело диалоговое окно, файл оставался на месте, удалялся только после нажатия ОК.
hcn писал(а): 14.03.2020,22:59 чтобы слить второй раздел пофайлово, вам придется как-то его смонтировать.
Я с него уже всё скопировал из-под Соляриса через NFS.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 15.03.2020,10:46

Arix писал(а): 15.03.2020,09:24 Без сжатия скорость 800 кб/с
Маловато, но ничего не сделать. С другой стороны сжатие уже не выглядит настолько медленным.
Arix писал(а): 15.03.2020,09:24
hcn писал(а): 14.03.2020,22:59 тогда добавьте для dd параметр count=X
X - в каких единицах? Я хочу по гигабайту, написал 1073741820.
Оказывается, в мегабайтах. Первый кусок прошёл, и на этом всё закончилось.
Единицы те же, что указаны в bs, то есть да, мегабайты. Они же указываются в seek=.
Пересчитываете смещение и запускаете dd | nc снова, никакой другой магии тут не предусмотрено.
Arix писал(а): 15.03.2020,09:24
hcn писал(а): 14.03.2020,22:59 предварительно их подрезав
Как?
Например: truncate -s806M dump0
Подрезка нужна, если обрыв был в произвольном месте и / или навели последующий dd на более ранний блок, то есть где получается пересечение.
Когда ошибок при передаче нет, подрезка не требуется.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 15.03.2020,10:48

gzip: disk001.gz: unexpected end of file, да, это логично. Обходится zcatом, он распакует столько целых блоков, сколько сможет. Попробуйте zcat disk001.gz > disk001
На самом деле что gunzip, что zcat - это обертки вокруг gzip с сключами -d и -cd соответственно. gunzip -c < disk001.gz > disk001 и gzip -cd < disk001.gz > disk001 дадут тот же самый результат.
Последний раз редактировалось hcn 15.03.2020,11:15, всего редактировалось 1 раз.

Arix
Advanced Member
Сообщения: 2384
Зарегистрирован: 18.07.2015,08:56
Откуда: Саратов

SUN Sparcstation 20 - вопросы

Сообщение Arix » 15.03.2020,11:14

hcn писал(а): 15.03.2020,10:46 Единицы те же, что указаны в bs, то есть да, мегабайты
Да, я уже это понял.
Первый гиг прошёл, на втором я обломался на 200 Мб. При этом комп завис. При второй попытке второй гиг прошёл, но я забыл указать count=1024. Остановил, обрезал. Плохо, что в НекстСтепе терминал после перезагрузки не помнит ранее вводимых команд. В Убунте проматываешь их стрелками, где надо подправляешь, ошибиться сложнее.
В общем, увлекательный процесс идёт. Заодно, я повышаю свои знания в Линуксе. :)
Последний раз редактировалось Arix 15.03.2020,12:14, всего редактировалось 2 раза.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 15.03.2020,11:17

У меня есть bash-4 и zsh-3, в которых уже комфортно работать, но я сейчас не могу собирать их под sparc. Попробую вечером.
Последний раз редактировалось hcn 16.03.2020,00:16, всего редактировалось 1 раз.

Arix
Advanced Member
Сообщения: 2384
Зарегистрирован: 18.07.2015,08:56
Откуда: Саратов

SUN Sparcstation 20 - вопросы

Сообщение Arix » 15.03.2020,13:32

На пятом гигабайте начались проблемы. Проходит минут 12, пока мы добираемся до его начала. Но дамп начинает делаться с начала диска! Открываю его как текст, в начале стоит строка
SUN9.0G cyl 4924 alt 2 hd 27 sec 133,
точно такая же, как в самом первом гигабайте. И дальше всё одинаково. Я подумал, может я skip и count написал не в том порядке. Нет, не в этом дело. Две попытки, и оба раза сначала, хотя проходит время, прежде чем начинается передача.
Что за чертовщина?? Диск 9,1 Гб.

Попробовал начать с четвертого гигабайта без ограничения на размер куска. Как только прошёл гигабайт, шум диска изменился. Похоже, головки всё равно перешли на начало. Да, так и есть, в дампе присутствует строка SUN9.0G cyl 4924 alt 2 hd 27 sec 133.

Вот распечатка разделов диска, сделанная в Солярисе:
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t1d0s0    4131384 2981634 1108437    73%    /
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
/dev/dsk/c0t1d0s7    4055498 1302523 2712421    33%    /export/home
swap                  861776     216  861560     1%    /tmp
Судя по этому, системный раздел укладывается в 4 Гб, он сдамплен полностью.

Я подумал: а почему бы из-под Соляриса такое не провернуть. Ведь dd там тоже работает. Ах, сетевого кота там нет... Но можно сохранять дампы в файл на второй раздел, потом забирать их оттуда по NFS. Сдампил для пробы первые 10 Мб первого раздела. Сравнил с первым гигабайтом, снятым из-под Некста. и обнаружил странность. Дамп начинается со строки XDrawPoints.\f2display drawable\. А в дампе всего физического диска эта последовательность встречается только через 500 Мб. Дальше всё совпадает. Такое ощущение, что первый раздел начинается не с начала диска. Тогда он не влезает полностью в 4 Гб, которые мне удалось сдампить из-под NextSTEP. Может, в начале диска есть бэды, вот эту область и пропустили. Тут хорошо бы увидеть не просто список разделов, а карту диска, как, например, в Акронисе.

Аватара пользователя
hcn
Advanced Member
Сообщения: 490
Зарегистрирован: 09.12.2019,01:34
Откуда: Cанкт-Петербург

SUN Sparcstation 20 - вопросы

Сообщение hcn » 15.03.2020,23:29

Arix писал(а): 15.03.2020,13:32 Две попытки, и оба раза сначала, хотя проходит время, прежде чем начинается передача.
Попробовал начать с четвертого гигабайта без ограничения на размер куска. Как только прошёл гигабайт, шум диска изменился. Похоже, головки всё равно перешли на начало. Да, так и есть, в дампе присутствует строка SUN9.0G cyl 4924 alt 2 hd 27 sec 133.
Не совсем понял, dd в принципе реагирует на skip, но после опеределенной физической границы переходит в начало?
У меня образы до сих пор были не больше 2G, я просто не сталкивался.
Судя по всему, ядро NeXTSTEP и libc ни в зуб ногой на тему смещений больше 32 бит. Ну, тогда откладываем NeXTSTEP на время.
Arix писал(а): 15.03.2020,13:32 Я подумал: а почему бы из-под Соляриса такое не провернуть. Ведь dd там тоже работает.
Проблема в том, что корень у вас обычно смонитрован на запись, любой дамп получится грязным либо просто нерабочим. Но если пишется мало данных, может и прокатить, насколько хорошо получился дамп, можно проверить в Linux.
Тут еще вопрос, что делать дальше. Подменный диск скорее всего будет больше нынешнего, если просто залить на него дамп, то выгоду от объема почувствовать будет трудно. Из-под NeXTSTEP мы пытались слить весь диск только потому, что это наиболее полный бекап, из которого впоследствии можно достать все. К тому же оказалось, что разметку sd0 NeXTSTEP не воспринимает. В Solaris такой проблемы нет - можно обойтись тарболами корня и home (уже готово), такой бекап будет чище и меньше. Будущий корень Solaris целесообразно сделать поменьше, чтобы в пределах досягаемости загрузчика OBP можно было разместить еще что-нибудь. Как вариант - разместить в первых 2G ОС, чей вторичный загрузчик спобоный загрузить любую ОС. Кстати, не всякий установщик способен корректно установить OC в раздел отличный от a, NetBSD пришлось ставить руками. Всего на одном диске было 3 *BSD, Linux и OSol, но FreeBSD довольно быстро снес из-за постоянных падений ядра.
Arix писал(а): 15.03.2020,13:32 Может, в начале диска есть бэды, вот эту область и пропустили. Тут хорошо бы увидеть не просто список разделов, а карту диска, как, например, в Акронисе.
format -e
0
verify
q
► Показать

Ответить