понедельник, 25 февраля 2008 г.

Перемонтируем /home на новый HDD в Ubuntu Linux

В самом начале своего знакомства с unix-like системами я всегда выделял очередному линуксу/фре достаточно мало места, по умолчанию я использовал Windows XP и львиная доля HDD всегда доставалась этой ОС. С тех пор много чего изменилось, а я и не заметил, как уже более полугода работаю, выхожу в Интернет, слушаю музыку, смотрю фильмы, ТВ, etc находясь в своей уже полюбившейся(удобной, надёжной, защищённой и далее по тексту) ОС, а в Windows загружаюсь очень и очень редко - поиграть (да, есть такой грешок за мной :)).

Логично, что места на разделах, выделенных для линукса, стало катастрофически не хватать, особенно в своей домашней директории /home. Разумным выходом из сложившейся ситуации мне показалось следующее решение - перемещение /home на отдельный свободный (благо он есть) винчестер, в этой роли выступает Seagate SATA 80 Gb.
Первое место, где я ищу информацию по интересующему меня вопросу, это... нет, не Google, с недавних пор это планета runix.org. Полезной оказалась заметка mczim`a.
После этого я нагуглил вот это(англ.) небольшое руководство. Итак.

После подключения винчестера по всем правилам, он у нас должен появиться в /dev. В моем случае появился /dev/sdb.
Во-первых, форматируем наш новый винчестер и создаем раздел:


# fdisk /dev/sdb
# mkfs.ext3 /dev/sdb1

Проверить, что все идет по плану можно командой:

# fdisk -l

После этого, монтируем наш новый hdd в какое-нибудь место, например в /share/newhome, копируем содержимое папки /home в /share/newhome и не забываем после копирования отмонтировать новый hdd:

# mount /dev/sdb1 /share/newhome
# cp -vax /home /share/newhome
# umount /dev/sdb1

Теперь прописываем новый hdd в /etc/fstab. Тут есть одна тонкость - дело в том, что в Ubuntu в /etc/fstab вместо названий устройств (/dev/hda1, /dev/hda2, etc) используется UUID. Чтобы узнать UUID нашего нового hdd выполняем команду:

# ls -l /dev/disk/by-uuid/

Предварительно, на всякий случай, сделав резервную копию /etc/fstab, копируем нужный нам UUID вместо UUID старого раздела(надеюсь /home у вас вынесен в отдельный раздел?).
Строка монтирования домашнего раздела в моем случае выглядит так:

# /dev/sdb1
UUID=3dbf409b-c35e-482c-8464-59b85528f714 /home ext3 defaults 0 2

Тут можно вписать кучу параметров монтирования разделов типа ext3 или поменять режим журналирования - на Ваше усмотрение. По умолчанию ext3 раздел примонтируется в режиме "ordered", а в /var/log/messages будут выведены строчки:

Feb 25 19:13:44 fabian kernel: [ 32.474467] EXT3 FS on sdb1, internal journal
Feb 25 19:13:44 fabian kernel: [ 32.474473] EXT3-fs: mounted filesystem with ordered data mode.

Тут сказано, что это нормально :)

Обратите внимание на последнюю цифру "2" в строчке монтирования раздела. Вначале я по ошибке поставил там единицу, на что при загрузке Ubuntu ругалась, что не может примонтировать раздел. В man fstab по поводу этого параметра сказано следующее:

The sixth field, (fs_passno), is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2.

Т.е. для "/" должна быть указана единица, а для других ФС - двойка. Поменял на двойку, Ubuntu загрузилась без ошибок.

В исходном руководстве сказано, что можно, не перезагружая компьютер, набрать команду

# mount -a

и наш новоиспечённый /home примонтируется, но тогда при выводе команды

# df -H

вы увидите, что два раздела смонтированы на /home. Чтобы этого избежать, необходимо сначала отмонтировать старый раздел, на котором расположен /home. Отмонтировать этот раздел при рабочей запущенной ОС достаточно не ординарная задача, ведь существует масса процессов, которые "занимают" этот раздел. Вообще говоря, мне показалось, что проще перезагрузиться. :)

Если все прошло как надо, то после перезагрузки, /home уже будет на новом разделе.

Что было у меня ДО:

root@fabian:/home/fab# df -H
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sda10 12G 9,9G 689M 94% /home


ПОСЛЕ:

root@fabian:/home/fab# df -H
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sdb1 79G 12G 64G 15% /home


Вот и все.


Читать далее...

воскресенье, 17 февраля 2008 г.

RAID. Intel matrix storage

Предисловие.

Не знаю как в других компаниях, но в компании, где я подрабатываю сисадмином, святая святых компании - бухгалтерия. Недавно бухгалтеру поменяли компьютер, заказывал "самый главный компьютер" компании я, заказывал у компании-партнёра, у которой мы покупаем компьютеры лет 5 уже. В ходе общения с манагером по продажам я, наверное, раз 10 упомянул, что компьютер должен быть меганадежным. Меня заверили, что он будет таковым. Через месяц привезли компьютер, в котором были по разным причинам поменяны комплектующие (процессор, память, корпус...) и стоял БП от Microlab. Я давно не копался в комплектующих и, можно сказать, не совсем в теме, поэтому подумал, что раз они поставили Microlab, значит Microlab стал выпускать офигенные БП, получше FSP и тем более HEC, Delta или Thermaltake. К слову сказать, все купленные у этой конторы компьютеры работают стабильно (тьфу-тьфу-тьфу).

В "самый надежный компьютер" компании поставили мать Intel S3000AH с софтварным RAID Intel Matrix на борту, в мать установили Intel Xeon и 2 Gb RAM, к RAID подключили 2 HDD WD 160 GB SATA. И - не забываем - блок питания Microlab 420W.
Во-первых, ещё на этапе установки ЗлоХП выяснилось, что флоповод не работает и, соответственно, драйвер RAID`а мне было не поставить. Пришлось снимать флопик с соседского компьютера.
"Беда пришла откуда не ждали" - это не про нас :)
В один прекрасный день позвонил главбух, потом ещё раз. Звонки главбуха стали раздаваться с завидной регулярностью, а описание главбухом происходящего напоминало театр военных действий.
Сначала перестала работать мышь, потом клавиатура - лечился сей недуг жоским reset`ом. Затем по очереди стали вырубаться USB порты - сначала на морде корпуса, затем и сзади. Тут стоит отметить, что все USB порты были забиты различного рода USB ключами к 1с, банк-клиенту и прочими, соответственно, неработоспособность USB портов автоматически означала неработоспособность основных программ главбуха, а значит и всей конторы целиком.

К моему приезду "самый надёжный компьютер" вообще отказался запускаться, зависая на этапе загрузки ОС, и никакие ухищрения (сброс BIOS, безопасный режим, загрузка последней удачной конфигурации, etc) не помогали вернуть компьютер к жизни. "Почему-то" решил попробовать заменить БП Microlab на запасной - FSP 400W. После замены ЗлоХП запустилась, но запустилась она без включённого RAID (BIOS сбрасывался). После загрузки ЗлоХП с выключенным RAID`ом грузиться с включённым RAID`ом она отказалась, ругаясь на то, что не может найти какой-то файл в system32/config. Насколько я понял, ЗлоХП отказалась грузиться с RAID`а в связи с тем, что данные на двух винчестерах рассинхронизировались вследствие сбойной работы блока питания. Хотя, возможно, причиной послужила загрузка одного из винчестеров при выключенном RAID`е.
Чтобы восстановить работоспособность зеркала были выполнены следующие шаги:
1. Создание клона одного из винчестеров в зеркале на третий винчестер, дабы обезопасить себя от возможных косяков со стороны самого RAID`а при восстановлении.
2. Запуск машины с включённым RAID`ом, но без одного винчестера. RAID ругнулся на отсутствие второго винчестера и загрузился с первого.
3. Запуск машины с включённым RAID`ом и подключённым вторым винчестером. На этот шаг утилита Intel Matrix Storage отреагировала статусом "Rebuild" и сообщением, в котором говорилось, что процесс ребилда будет выполнен на уровне ОС. После загрузки ЗлоХП утилита Intel Matrix Storage запустила процесс "Rebuilging", которым занял примерно 40 минут.
4. Контрольная перезагрузка, убедился, что BIOS`овская утилиты выдала статус "Normal", загрузил ОС, проверил сообщение Intel Matrix Storage.
Вроде работает.

P.S. Это был мой первый опыт работы с RAID массивами вообще, и первый опыт с софтварным RAID + OS Windows XP в частности. Хорошо, что все хорошо закончилось и опыт не оказался "горьким".
А мораль сей басни такова - БП Microlab как были говном, так и остаются, а манагерам нашей компании-партнера, которая поставила в "самый надёжный компьютер" такой БП - что-нибудь бы оторвать, например руки. При встрече.


Читать далее...