SUN Sparcstation 20 - вопросы

DEC Alpha, ARM, MIPS, PowerPC, SPARC, VAX, PDP-8 и другие устройства
i8088
Advanced Member
Сообщения: 4383
Зарегистрирован: 30.01.2015,17:06
Откуда: г. Баку, Азербайджан

Конкурсы

Вклад в сообщество

SUN Sparcstation 20 - вопросы

Сообщение i8088 » 14.06.2020,10:05

Arix писал(а): 13.06.2020,20:04 Питание подается через несколько запараллеленных контактов. Вряд ли там контакт может пропасть
Ну так и ток там слегка побольше, чем сигнальные линии. Один контакт пропадет,
нагрузка на другие возрастет итд. Вспомните SATA.
Arix писал(а): 13.06.2020,20:04 А там эти долбаные молексы... В них постоянно пропадают контакты. Втыкаются туго, так, что потом фиг вытащишь, а контакта нет. Не понимаю, как так может быть
Обжимка провода - для надежности провода нужно припаять/пропаять. Бывает от
частых подключений часть жил внутри провода ломается, и это долго незаметно
может быть.

Ваши диски можно проверить по нормальному, с помощью MHDD и контроллера
ADAPTEC (можно и другой, только DOS драйвер SCSI поменять). Если по всем секторам
будет ABORT/IDNF, делайте LLF.
Кай писал(а): 13.06.2020,21:35 Привод - дохлятина. Ставьте Fujitsu, они надёжнее.
За старые Fujitsu не скажу, а относительно новые 73GB и 150GB мне совсем не понравились, греются
сильнее чем мои Seagate (Cheetah 10K.7) и при той же наработке (~5 лет) уже есть долгочитаемые
секторы. В целом в моем SCSI хозяйстве эти Seagate (есть и SCA, и обычные)лучшие, но все конечно
зависит от конкретной модели.

Еще есть у меня пара 2GB Seagate Narrow SCSI, один 2GB wide. И 6шт 1GB SCA дисков HP, которые явно
перемаркированный Seagate. Претензий к ним не имею.

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

SUN Sparcstation 20 - вопросы

Сообщение Arix » 14.06.2020,16:29

Навёл мосты между Sun'ом и главным компьютером через SSH. Он есть и в NetBSD, и в Солярисе, причем, в последнем даже не потребовалось ничего настраивать, видимо, предыдущий хозяин позаботился. Gnome Commander в Линуксе умеет работать с SSH. Это чрезвычайно удобно. В Windows я поставил плагин SFTP в Total Commander, так что, теперь и из-под винды можно заходить. Можно бэкапить диски и восстанавливать из бэкапа, минуя запись файлов на локальные диски. Правда, очень медленно, но как-то уже боязно стало дергать диски туда-сюда. Тем более, это будет неудобно, когда я закрою комп, а на нём ещё будет стоять монитор.

Зашёл Тотал командером в папку /dev, а там файлы rsd1b и rsd1d имеют размер как у соответствующих разделов диска. Попробовал просто скопировать один из них, который поменьше. Что-то процесс остановился на 99%, ТС "не отвечает". Прибил его, перезапустил - файл полностью скопирован и совпадает с ранее скопированным образом. Так что, для бэкапа можно просто копировать файлы устройств.
i8088 писал(а): 14.06.2020,10:05 Ваши диски можно проверить по нормальному, с помощью MHDD и контроллера
ADAPTEC (можно и другой, только DOS драйвер SCSI поменять). Если по всем секторам
будет ABORT/IDNF, делайте LLF.
Два диска не раскручиваются, им LLF вряд ли поможет. А вот, третий... Я его начал форматировать в Солярисе, программа показала что процесс займёт 57 минут. Когда я согласился, она написала что-то про таймаут, далее было написано что-то про 7000 секунд. Это уже явно не 57 минут. И было непонятно, идёт процесс или нет. Никакой прогресс-индимкации, диск не шумит. Я это дело отменил. И после этого диск тоже перестал работать. Но он крутится, всеми системами и БИОСами определяется. Однако, программы для работы с дисками с ним работать не хотят. Либо диска нет в списке, либо выдаются ошибки. Разве прерванное форматирование может убить диск? Так вот, непонятно, то ли он сдох во время форматирования, то ли потом, когда я его воткнул в РС через переходник.
Последний раз редактировалось Arix 14.06.2020,19:41, всего редактировалось 2 раза.

i8088
Advanced Member
Сообщения: 4383
Зарегистрирован: 30.01.2015,17:06
Откуда: г. Баку, Азербайджан

Конкурсы

Вклад в сообщество

SUN Sparcstation 20 - вопросы

Сообщение i8088 » 14.06.2020,17:26

Arix писал(а): 14.06.2020,16:29 Разве прерванное форматирование может убить диск?
Доступа к носителю не будет, если LLF до конца не дошло. Прогресса операции обычно и нет, тк
форматирование делает сам диск, а не программа. Но во FreeBSD предусмотрена возможность
запрашивать диск (это в зависимости от того, как была подана команда FORMAT UNIT), относительно
статуса операции, см man camcontrol

На других дисках скорее всего электроника вышла из строя (микросхема управления
двигателем возможно), из-за пропадания одного из напряжений.

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

SUN Sparcstation 20 - вопросы

Сообщение Arix » 14.06.2020,19:25

i8088 писал(а): 14.06.2020,17:26 Доступа к носителю не будет, если LLF до конца не дошло
Это было форматирование в программе format в Солярисе. Разве оно там низкоуровневое? Похоже, что да.

Запустил LLF через БИОС контроллера. Диск вернулся к жизни!
Cпасибо за подсказку! Вообще, у меня мелькала мысль про низкоуровневое форматирование.

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

SUN Sparcstation 20 - вопросы

Сообщение Arix » 15.06.2020,08:32

Кай писал(а): 13.06.2020,22:49 700 МБ болванки он читать и не обязан. Там есть ограничения.
Да уж, попробуй сейчас найди болванки на 650 Мб.
Хотя, на Авито есть.
Кай писал(а): 13.06.2020,22:55 У меня есть привод от SS20 - Sony, он читает больше, чем "Тошка".
А он RW читает?

Аватара пользователя
Кай
Почётный пользователь
Сообщения: 19738
Зарегистрирован: 08.08.2010,21:44
Откуда: СПб, Ульянка-Лигово
Контактная информация:

Вклад в сообщество

SUN Sparcstation 20 - вопросы

Сообщение Кай » 15.06.2020,09:29

А он RW читает?
Нет.

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

SUN Sparcstation 20 - вопросы

Сообщение hcn » 15.06.2020,23:28

Arix писал(а): 14.06.2020,16:29 Так что, для бэкапа можно просто копировать файлы устройств.
Это лучше, чем ничего, конечно, но вы нагрузку от sshd смотрели? Шифрование довольно затратно, оно может сдерживать больше, чем сеть. Дампы блочных устройств лучше пропускать через компрессор с netcatом, они выдадут максимум возможного, если компрессор подобрать, как следует. Для затравки:
pkg_add lzop zstd
for arc in lzop gzip zstd ; do dd if=/dev/rsd1b bs=1m count=16 2>/dev/null | $arc -1 | dd of=/dev/null ; done
Еще лучше переключиться на передачу файлов, а не дампов, например, можно поднять rsyncd на Ubuntu и сливать файлы туда - вся мощь rsync и никаких расходов на шифрование. Разве что в NS проще обойтись tarом, актуальный rsync, боюсь, будет проблемой.
Кстати, перелистал тему и не нашел упомниния, какой в вашем SS-20 процессор. Помимо названия интерес представляют результаты 7z b и openssl speed 2>/dev/null (первый тест достаточно быстрый, второй занимает минут 15; если не затруднит, конечно).

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

SUN Sparcstation 20 - вопросы

Сообщение Arix » 16.06.2020,11:30

Да, как оказалось, отключить шифрование в SSH нельзя. По ssh -Q cipher нет "none". Total Commnader показывает скорость то 200, то 400 кб/с. В среднем получилось 277 кб/с. Через FTP скорость 850 кб/с. Так что, для передачи больших файлов SSH малопригоден. Однако, он удобен тем, что поддерживается файловыми менеджерами. Я могу прямо из-под винды гулять по всей файловой системе, править конфиги в Bred'e. Это гораздо удобнее, чем через vi. Что я уже делал.
Я на оставшемся месте диска с Линуксом, НетБСД и NS создал раздел с файловой системой 4.2BSD. В disklabel он у меня идёт под буквой f. Работает. Я смонтировал разделы Соляриса. А вот, наоборот, из Соляриса смонтировать разделы NetBSD что-то не получается. Хотя, файловая система, насколько я понимаю, у них одинаковая - UFS.
mount: /dev/dsk/c0t3d0s5 is not this fstype.
Перебрал все "s". 1 - 5 - данное сообщение. На s6 и s7 - I/O Error. Это понятно, этих разделов нет.
hcn писал(а): 15.06.2020,23:28 Еще лучше переключиться на передачу файлов, а не дампов
А если диск гикнется? Помимо файлов надо ещё будет как-то загрузку восстанавливать. А на системном разделе есть жесткие и символьные ссылки, они не пострадают?

Эксперименты.
Сжатие в gzip идёт со скоростью 315 кб/с.
Сохранение образа диска в файл без сжатия на другой физический диск - 384 кб/с. Почему-то медленнее, чем по сети на другой компьютер.

Хотел попробовать netcat, но он не хочет работать. Я пишу nc -l -p 1234, как в этом сообщениеи. А он вываливает справку. При этом не выдает ошибок. Может, в НетБСД у него синтаксис другой?

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

SUN Sparcstation 20 - вопросы

Сообщение hcn » 17.06.2020,00:50

Arix писал(а): 16.06.2020,11:30 Да, как оказалось, отключить шифрование в SSH нельзя. По ssh -Q cipher нет "none". Total Commnader показывает скорость то 200, то 400 кб/с. В среднем получилось 277 кб/с.
На lo интерфейсе 220R (USII 360 MHz x 2):
aes128-cbc 7,2 MB/s
aes256-cbc 6,0 MB/s
aes128-ctr 7,1 MB/s
aes256-ctr 6,1 MB/s
aes128-gcm 7,0 MB/s
aes256-gcm 6,1 MB/s
chacha20-poly1305 4,3 MB/s
blowfish-cbc 6,4 MB/s
arcfour 10,6 MB/s
Arix писал(а): 16.06.2020,11:30 Хотя, файловая система, насколько я понимаю, у них одинаковая - UFS.
Основа одинаковая, но как часто бывает, есть нюанс. В NS как бы тоже UFS.
hcn писал(а): 15.06.2020,23:28 А если диск гикнется? Помимо файлов надо ещё будет как-то загрузку восстанавливать.
А кто знает, какой будет новый диск, возможно, там и разделы захочется напилить по-другому. И NS таки работает, хотя дамп был не пригоден для заливки.
Arix писал(а): 16.06.2020,11:30 А на системном разделе есть жесткие и символьные ссылки, они не пострадают?
Не пострадают.
Arix писал(а): 16.06.2020,11:30 Сжатие в gzip идёт со скоростью 315 кб/с.
В /dev/null? Lzop будет точно быстрее, но с худшей степенью сжатия.
Arix писал(а): 16.06.2020,11:30 Что-то dd выпендривается.
Ещё не принимает запись вида "3000M" - неправильное число. Хотя в инструкциях написано, что можно так указывать.
В NetBSD - m. Команду из моего предыдущего сообщение пробовали?
Arix писал(а): 16.06.2020,11:30 Хотел попробовать netcat, но он не хочет работать. Я пишу nc -l -p 1234, как в этом сообщениеи. А он вываливает справку. При этом не выдает ошибок. Может, в НетБСД у него синтаксис другой?
И nc об этом честно пишет: [-p source_port] ... [destination] [port]
Вам нужен просто nc -l 1234.

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

SUN Sparcstation 20 - вопросы

Сообщение Arix » 17.06.2020,21:33

hcn писал(а): 17.06.2020,00:50В /dev/null?
Нет, на диск. Да, Lzop сжимает гораздо быстрее. Размер архивного файла с диском Линукса sd1b получается таким же, как и gz. С /dev/null у меня какая-то чертовщина.
Я пишу:
gzip -1 filename > /dev/null
lzop -1 filename > /dev/null
Процесс прошёл. Я запускаю эти команды по-новой. Оба архиватора сообщают, что файл уже существует. Гзип его перезаписывает, лзоп - нет. Как в /dev/null что-либо может существовать?
hcn писал(а): 17.06.2020,00:50 Команду из моего предыдущего сообщение пробовали?
Попробовал. Долго переписывать вывод. B сокращенном виде получается так:

6,010 secs 1109870 bytes/s
25.102 - 262509
22.059 - 298391

C DD уже разобрался, поэтому и удалил это из своего сообщения. Какой угодно bs задавать нельзя, надо степень 2. Я думал, что с bs он будет нарезать файл на куски заданного размера. Вот и хотел задать один кусок на 9 Гб. Или три куска по 3 Гб. Оказывается, не нарезает.

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

SUN Sparcstation 20 - вопросы

Сообщение hcn » 18.06.2020,11:33

Arix писал(а): 17.06.2020,21:33 gzip -1 filename > /dev/null
lzop -1 filename > /dev/null
Процесс прошёл. Я запускаю эти команды по-новой. Оба архиватора сообщают, что файл уже существует. Гзип его перезаписывает, лзоп - нет. Как в /dev/null что-либо может существовать?
Надо было изучить, как gzip и прочие компрессоры работают с агрументами. Если подать поток co stdin, то есть gzip -1 < filename > /dev/null, ошибки не будет. Ошибки не будет, если указать, что сжатый поток надо отправить на stdout: gzip -c1 filename > /dev/null. В вашем случае gzip пытается создать filename.gz, но файл уже существует.

Ответить