Пара вопросов UNIX-оидам

[Vasik]

Появилась у меня работа и первое чем пришлось занияться - это восстанавлением работоспособности серверов после глобального отключения электричества в нашей местности.
На юникс серверах посыпались файловые системы.
Под соляркой на нетрах удалось восстановить, но работая с одним из сереверов через последовательную консоль с LOM столкнулся с такой неприятной вещью. Когда отсоединяюсь в виндовозном гипертерминале от консоли, то сервер вываливается из операционки в ok prompt.
Причём на первом сервере такой засады не было, но сейчас сложно утверждать, так как работал с первым сервером в другой день из другого профиля, возможна была другая настройка соединения.
Подозрение что терминальная программа шлёт последовательность которая совпадает с кодом выхода в openboot. Как с этим бороться или чего я не так делаю? Или вообще просто нужно выдергивать кабель, не разрывая соединения в терминале?

Второй вопрос - какие есть утилиты что бы восстановить или попытаться спасти информацию с линуксового раздела на винте? (RH7.2). fsck - не помогает и даже не стартует, говорит что не может распознать партицию.
Насколько я могу судить по записям в fstab - раздел был ext3. Странно что полетел.
Как сказал шеф, информация там довольно ценная и нужно сделать всё возможное что бы спасти и скопировать раздел на другой винт, если получится. Кто что посоветует, если был подобный опыт?

[idle0]

http://sunsolve.sun.com/pub-cgi/retriev ... qs%2F60682

DESCRIPTION:
We connect to the Netra 1405 boxes using the Microsoft Windows
HyperTerm program. If this program is halted while connected to the
Netra 1405 box, it will cause the Netra to halt and drop to the OBP OK
prompt. How do you fix this ?


SOLUTION:
This is just the console receiving a break signal as the hyperterm program halts.
Type kbd -a disable at the console to prevent this.

Running "kbd -a disable" at a shell prompt will disbale keyboard interrupts.
After running this command, neither stop-a nor disconnecting the keyboard will
bring the system down to the ok prompt.

The same behavior can be created permanently by editing the file,
/etc/default/kbd. Add the following line to /etc/default/kbd:
KEYBOARD_ABORT=disable

You must then reboot the system for the change to take place. Again, after
making either of these changes, neither stop-a nor unplugging the keyboard can
bring the system to a halt.

[idle0]

http://www.ontrack.com/newsroom/pressre ... Release=83

ONTRACK REMOTE DATA RECOVERY SERVICE NOW SUPPORTS LINUX OPERATING SYSTEMS

[f_evgeny]

Второй вопрос - какие есть утилиты что бы восстановить или попытаться спасти информацию с линуксового раздела на винте? (RH7.2). fsck - не помогает и даже не стартует, говорит что не может распознать партицию.

Возможно повреждена Partition Table? Тогда можно попробовать gpart

[Vasik]

Thanks for help, guys.
I am writing from my job place, so now I can tell more details of this Linux box HDD problem.
Partition is ext2.
I have attached another one HDD with slightly bigger size (but both are about 40 Gb).
Using fdisk I have created a partition ext2 on the new drive.
And now I am copying from one damaged partition to another one with this comand:
dd if=/dev/hdb1 of=/dev/hdd1

Am I doing right?

It's about 2 hours and I could not estimate time it will take to be done.
Let me know any points and ideas.
Thanks.

[Vasik]

Вопрос с восстановлением винта решился. Сама операция копирования раздела на другой винт заняла 6 часов (застрелиться ). Чудес не бывает - этот винт также определялся как загамаченный, зато получилась точная копия первого винта.
На этой копии решил и потренироваться и уже даже нашёл стороннюю утилиту, которая обещала восстановить винт, но ещё раз перечитав до конца man e2fsck меня озарило - я пробовал альтернативный суперблок с ключом -b 8193, как предлагала утилита по умолчанию не найдя возможности использовать основной, но поскольку винт большой, то там кластеры 4-х килобайтные, поэтому альтернативный суперблок нужно задавать было с числом в четыре раза больше. Указав нужную цифру, e2fsck сразу всё распознала и дальше в течение нескольких минут восстановила практически всё как было (надеюсь что так, поскольку там всего добра было на 10 Гиг - теперь пусть программеры разбираются всё ли как было ).
Всем спасибо.

[idle0]

RTFM - великая вещь!

[alder]

Сама операция копирования раздела на другой винт заняла 6 часов

Почти наверняка ядро само не инициализирует DMA (спросите у него hdparm -d /dev/hda). А с PIO у него обычно только очень медленно получается читать. Попробуйте подсказать ему о DMA: hdparm -d 1 /dev/hda. Скорость скорее всего вырастет до максимально поддерживаемой винтом. Проверьте через hdparm -t /dev/hda. Еще немного улучшить картину может: hdparm -u 1 -c 1 -d 1 /dev/hda

[Vasik]

Alder, спасибо за отличную наводку. На работе посмотрю - интересно конечно сравнить, до этого не смотрел, суета - всё вылетело из головы .
А сейчас дома поигрался на домашней тачке, забавная картинка получается - некоторые параметры лучше выключать (железо древнее) - тогда по тесту получается быстрее:

root@linux05 /root]# hdparm -c 0 -u 1 -d 1 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 0
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)

[root@linux05 /root]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 64 MB in 14.74 seconds = 4.34 MB/sec

[root@linux05 /root]# hdparm -c 1 -u 1 -d 1 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 1
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)

[root@linux05 /root]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 64 MB in 15.05 seconds = 4.25 MB/sec

root@linux05 /root]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 64 MB in 17.94 seconds = 3.57 MB/sec

[root@linux05 /root]# hdparm -c 0 -u 1 -d 1 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 0
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)

[root@linux05 /root]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 64 MB in 15.07 seconds = 4.25 MB/sec
_________

Даже с одинаковыми параметрами запущенные во второй раз тест даёт разные результаты, причём вместо ожидаемого ускорения за счёт буферизации, которая всегда присутствует в операционке, получается замедление.

[Vasik]

DMA на работе у винтов был включён, что давало производительность около 10 с половиной мег в секунду. После введения параметров c -1 и u -1 производительность увеличилась в полтора раза.
Так что всё равно, по моим прикидам что бы 40 Гиг перегнать с помощью dd пришлось бы часа 4 ждать в лучшем раскладе.