- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет.
Стоял-работал сервер с SW RAID-1 на двух дисках - sda и sdb.
sda в один момент умер. Удалили из массива, поменяли, запустилась пересборка, но тут оказалось, что и sdb содержит битые секторы, после пересборки статус массива:
md3 : active raid1 sda4[2](S) sdb4[1]
1908232704 blocks [2/1] [_U]
в dmesg:
kernel: raid1: sdb: unrecoverable I/O read error for
block 1927675136
kernel: md: using 128k window, over a total of 1908232704
blocks.
kernel: raid1: sdb: unrecoverable I/O read error for
block 1927675136
Крайне важно пересобрать массив, пусть даже если пара блоков потеряется. Как можно зафорсить пересборку, если не читается сектор?
Если вдруг нельзя, то мысли идут в сторону dd с одного раздела на другой. Но проблема в том, что на /dev/md3 - физический том LVM:
# pvdisplay
--- Physical volume ---
PV Name /dev/md3
VG Name vz
PV Size 1.78 TB / not usable 512.00 KB
Allocatable yes
PE Size (KByte) 4096
Total PE 465877
Free PE 11669
Allocated PE 454208
PV UUID a75RGy-ilp6-gU28-rJzD-HJYo-iTyr-pvRyny
и множество lv-разделов.
Если сделать еще один - md4 - и потом dd-ом загнать туда данные, как потом указать, что PV теперь на /dev/md4 живет?
1) Отключаем сборку raid
2) Делаем полную копию на новый диск при помощи dd, пропуская плохие блоки
3) Грузимся с нового диска
4) Вставляем новый чистый диск
5) Запускаем сборку
А вообще надо SMART настраивать чтоб не было так больно и обидно.
Зачем вам это dd, если можно просто файлы скопировать даже с raid, который не собран? Второй диск ведь все равно вынимать .
Если проблемные сектора не заняты, то вообще без проблем считаете.
Если заняты - узнаете даже какие именно файлы битые.
Ибо dd кошерно
Стоял-работал сервер с SW RAID-1 на двух дисках - sda и sdb.
sda в один момент умер. Удалили из массива, поменяли, запустилась пересборка, но тут оказалось, что и sdb содержит битые секторы, после пересборки статус массива
Вам наука:
1) настроить мониторинг smart-параметров
2) регулярно запускать smart-тесты дисков
2) регулярно проверять райд (в дистрибутивах есть кронтабы, как правило)
3) регулярно делать fsck (тем более, у вас LVM)
Крайне важно пересобрать массив, пусть даже если пара блоков потеряется. Как можно зафорсить пересборку, если не читается сектор?
Консервативный метод (просто копируем файлы на другой диск с нужной разбивкой/LVM-разделами) - вам уже советовали.
Но, если хотите - можете записать что-то в "битые" сектора с помощью hdparm --write-sector. Проблема в том, что вы заранее не знаете все битые сектора... Т.е. сперва, по-хорошему, вам badblocks надо будет прогнать.
PS: http://smartmontools.sourceforge.net/badblockhowto.html
Спасибо за ответы.
Вы, конечно, не поверите, но проверка смарта и статуса массива выполняется каждые 30 минут. Два диска сбойнули одновременно скорее всего из-за перегрева.
Сейчас сделал
hdparm --write-sector 1927675136 --yes-i-know-what-i-am-doing /dev/sdb
Но меня настораживает, что
hdparm --read-sector 1927675136 /dev/sdb
перед этим не выдавал сообщение об ошибке, а считывал сектор (нули выдавал).
Сообщение из dmesg о блоке - 1927675136 это именно блок с таким номером, его не надо высчитывать исходя из разбивки диска по партициям?
---------- Добавлено 31.05.2012 в 21:25 ----------
...
Да, и еще - если сделать dd с одного диска на другой, а потом поменять физически кабелями их местами - такой вариант прокатит?
То есть делаем dd с /dev/sdb на /dev/sda, выключаем машину, выкидываем диск /dev/sdb, на его место подключаем /dev/sda и грузимся.
---------- Добавлено 31.05.2012 в 21:47 ----------
Похоже, все-таки путаница между блоками и секторами получается.
Ядро выдает: kernel: raid1: sdb: unrecoverable I/O read error for
block 1927675136
hdparm --read-sector 1927675136 /dev/sdb считывает нормально.
Как по номеру блока (1927675136) вычислить сектор для его перезаписи через hdparm?
---------- Добавлено 31.05.2012 в 22:15 ----------
ну и сам себе отвечу...
Прогнал тест smartctl, нашел сбойный блок (через hdparm не читался), перезаписал, запустил ребилд.
Посмотрим.
Вы, конечно, не поверите, но проверка смарта и статуса массива выполняется каждые 30 минут.
Не поверю, конечно.
Сейчас сделал
hdparm --write-sector 1927675136 --yes-i-know-what-i-am-doing /dev/sdb
Но меня настораживает, что
hdparm --read-sector 1927675136 /dev/sdb
перед этим не выдавал сообщение об ошибке, а считывал сектор (нули выдавал).
Блок и сектор - вещи разные.
Вам наука: сперва ман читай, потом команду запускай...
Да, и еще - если сделать dd с одного диска на другой, а потом поменять физически кабелями их местами - такой вариант прокатит?
Ну, если мсье извращенец - почему нет? :)
Не поверю, конечно.
Блок и сектор - вещи разные.
Вам наука: сперва ман читай, потом команду запускай...
Ну, если мсье извращенец - почему нет? :)
Смотрите-ка, вы написали аж 4 фразы, которые не несут в себе никакого смысла, кроме стеба и издевательств. Не жалко потерянного времени и усилий нажатия кнопочек?
Все равно всем спасибо, что в процессе натолкнули на верный путь.
Смотрите-ка, вы написали аж 4 фразы, которые не несут в себе никакого смысла, кроме стеба и издевательств.
Давайте посмотрим.
1) "Не поверю, конечно.": Смотреть периодически на смарт-параметры и статус рейда - может и наивная мартышка. Это не то о чем вам писали выше - не запуск смарт-тестов, не проверка рейда. Вот почему вы проворонили проблему. Так понятно?
2,3) "Блок и сектор - вещи разные": вам "намекнули", что так вы просто могли себе убить (убили?) данные. Жаль, что вы ничему не учитесь.
4) Вам не понятно, почему ваш "такой вариант" нехорошо назвали? Ну например, потому что выше предложили решения, которые не требуют лезть в потроха сервера и ковырять железо.
Не жалко потерянного времени и усилий нажатия кнопочек?
В данном конкретном случае - уже жалко.