- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
запускаю fsck.ext3 /dev/md127 в rescue mode. оно пишет deleted inode has zero dtime?, я отвечаю yes. я так понимаю он исправляет эту ошибку и удаляет файл. так прошло минуты 2, потом дошло что не нужно было yes жать.
что теперь делать? он на обоих дисках удалял файлы?
И самое главное как в rescue mode узнать какой диск дохнет? или на каком ошибки пошли первоначально? smart ошибок не даёт.
fsck вы запускали по рейду ведь а не по диску, значит операция выполнялась на двух.
Покажите весь вывод:
cat /proc/mdstat покажет какой винт в строю, а какой улетел из рейда, Или утилиту atop поставьте и там смотрите.
fsck вы запускали по рейду ведь а не по диску, значит операция выполнялась на двух.
Покажите весь вывод:
в cat proc mdstat все UU
Seek Error Rate не очень хороший признак.
Запустите полный тест
Выполняется часов 6.
grey2, исходя из сказанного вами.... поясните лучше причину, по которой вы посчитали, что умер один из дисков..... А то смарты ваши.... выглядят более менее прилично, по крайней мере не вижу явных признаков при которых разваливается рейд обычно.... (чаще всего это DMA ошибки которые отражаются в SMART или наличие кучи плохих секторов, ни того ни другого не видать)...
WapGraf верно советует, надо придать диски long тесту..... станет понятнее....
И самое главное как в rescue mode узнать какой диск дохнет? или на каком ошибки пошли первоначально? smart ошибок не даёт.
raid поможет только при физическом отказе диска, а у вас было нарушение логической структуры (файловой системы) - поэтому это все отзеркалировалось наверняка нормально. Наличие рэйда не отменяет необходимости бэкапов ☝
cat /proc/mdstat покажет какой винт в строю, а какой улетел из рейда, Или утилиту atop поставьте и там смотрите.
Да, такое у hetzner нормальное явление - жд мрут, они у них старье. Мало того, просишь заменить ЖД, они живой снимают, пустой ставят, теряешь время на этом.
Seek Error Rate не очень хороший признак.
он то тут причем? - ошибки позиционирования для дисков - это нормально, их нетипичный рост может быть из-за перегрева блинов, но чисто технически - этот показатель ни о чем
долгий тест запускать не имеет смысла, так как если бы ошибки были в рабочей зоне (где находятся данные), то в смарте это бы отображено было, лонгтест имеет смысл при первом запуске (проверить не появились ли новые риаллокейты и т.п.)
он то тут причем? - ошибки позиционирования для дисков - это нормально, их нетипичный рост может быть из-за перегрева блинов, но чисто технически - этот показатель ни о чем
Ключевое слово "признак".
долгий тест запускать не имеет смысла, так как если бы ошибки были в рабочей зоне (где находятся данные), то в смарте это бы отображено было, лонгтест имеет смысл при первом запуске (проверить не появились ли новые риаллокейты и т.п.)
На практике это далеко не всегда так.