Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Если диск сыпаться начал — его выбрасывать надо, а не данные на нем размещать. Себе дороже выйдет.
Зачем так не оптимально? Есть еще возможность юзать дальше, где нет требования по сохранности данных. К примеру для тест-машин, которые создают тест-файлы, чтото с ними делают и выдают результат тестирования. То что может быть профакапится тест-файл это не критично для бизнеса.
>создают тест-файлы, чтото с ними делают и выдают результат тестирования
результат тестирования: невозможно прочитать файл. Тест провален.
результат тестирования: невозможно прочитать файл. Тест провален.
И что с того? Это бизнес-данные, потеря которых аукается по бизнесу? Нет же! Подумаешь ежедневный тест-набор не прошел, пройдет завтра. Это все же лучше чем сегодня покупать очередной за 2.5. Зачем тратить там где можно не тратить?
А зачем проводить такие тесты. Если результат тестирования может быть искажен неисправностью диска, то достоверность тестирования как бы сильно падает.
А вы действительно настолько «везучий» что у Вас все 100 кейсов из 100 возможных завалятся по причине жесткого? На практике если отработали 80% кейсов уже скажет о многом разработчику.
Более того плохо-работающее железо может выявить те случаи о которых разработчик даже не догадывался, но на которые его продукт должен адекватно реагировать!
К тому же тестирование это не ед. сфера применения жесткого. Его можно применить для временного хранения данных, к примеру меж сотрудниками организации. Развивайте фантазию, в любой организации, тем более в ИТ-сфере, дыр, которые требуют чтобы их закрыли очень много и на все нужно финансирование.
Надо всегда плясать от вопроса: «А что конкретно я хочу получить?», если у Вас требование: «100 процентная сохранность данных» тут даже думать не надо. Более-того даже если у вас отличный жесткий, то даже в этом случае на это не следует надеяться и следует подумать о бэкапе.
Более того плохо-работающее железо может выявить те случаи о которых разработчик даже не догадывался, но на которые его продукт должен адекватно реагировать!
К тому же тестирование это не ед. сфера применения жесткого. Его можно применить для временного хранения данных, к примеру меж сотрудниками организации. Развивайте фантазию, в любой организации, тем более в ИТ-сфере, дыр, которые требуют чтобы их закрыли очень много и на все нужно финансирование.
Надо всегда плясать от вопроса: «А что конкретно я хочу получить?», если у Вас требование: «100 процентная сохранность данных» тут даже думать не надо. Более-того даже если у вас отличный жесткий, то даже в этом случае на это не следует надеяться и следует подумать о бэкапе.
Если тесты не прошли, то нужно потратить время на анализ того, почему тесты не прошли, а это уже реальные денежные потери.
Мысль номер один:
В том-то и причина, что тесты заставляют взглянуть на причину поломки! Вспомните по какой причине мы, разработчики, отдаем тестировать продукт тестерам? Отдаем мы их потому что мы можем не заметить, а все потому что нам многое кажется очевидным и мы часто восклицаем «Тут багов не будет». Нам нужен взгляд со стороны на наше творение.
Так и с тестированием. Мы можем лелеять и сколь угодно долго утверждать «наши тесты выявляют все возможные баги» и даже не догадываться о каких-либо нюансах.
Если мы переместим тесты на поломанный жесткий, мы можем увидеть поломанный тест совсем не по тем причинам по которым мы ожидали планируя тест. Это еще один способ взглянуть на свой продукт совсем под другим углом зрения при тестировании.
Мысль номер два:
Не надо дожидаться отработки всего набора тестов. Надо поставить каждому тесту рейтинг или приоритет, а затем выставить их выполнение согласно рейтингу или приоритету. Возьмем случай тестирования класса строка и другого класса содержащего операции со строкой. Вопрос: Зачем ждать когда выполнятся тесты по строковым операциям, если класс строка имеет багу и тест это УЖЕ показал?
В том-то и причина, что тесты заставляют взглянуть на причину поломки! Вспомните по какой причине мы, разработчики, отдаем тестировать продукт тестерам? Отдаем мы их потому что мы можем не заметить, а все потому что нам многое кажется очевидным и мы часто восклицаем «Тут багов не будет». Нам нужен взгляд со стороны на наше творение.
Так и с тестированием. Мы можем лелеять и сколь угодно долго утверждать «наши тесты выявляют все возможные баги» и даже не догадываться о каких-либо нюансах.
Если мы переместим тесты на поломанный жесткий, мы можем увидеть поломанный тест совсем не по тем причинам по которым мы ожидали планируя тест. Это еще один способ взглянуть на свой продукт совсем под другим углом зрения при тестировании.
Мысль номер два:
Не надо дожидаться отработки всего набора тестов. Надо поставить каждому тесту рейтинг или приоритет, а затем выставить их выполнение согласно рейтингу или приоритету. Возьмем случай тестирования класса строка и другого класса содержащего операции со строкой. Вопрос: Зачем ждать когда выполнятся тесты по строковым операциям, если класс строка имеет багу и тест это УЖЕ показал?
>>Мысль номер один
Смысл тратить время разработчиков (которое стоит намного дороже нового диска) на поиск причины поломки, если реальной поломки небыло? Но придется, т.к. догадаться о том, что сбой теста произошел из-за ошибки чтения диска не так то просто.
Хуже всего, что может случится так, что тесты будут давать false-positive результат, из-за которого все больше и больше они будут игнорироваться разработчиками.
Если вам необходим случайный набор входных данных для тестов, то сгенерируйте его, для этого, кстати, есть специальные утилиты.
Но это уже будут не автоматические тесты, о которых я говорю, а стресс-тесты.
Этот тип тестирования так-же необходим, но возможно не в процессе ночных сборок.
>>Мысль номер два
Как это противоречит с тем, что я писал?
Естественно нужно исправлять ошибку, если тесты не проходят.
Я считаю, что проект должен быть всегда в исправном состоянии и все тесты до единого должны проходить успешно при ночных сборках, а также в процессе сборки релизной версии.
Смысл тратить время разработчиков (которое стоит намного дороже нового диска) на поиск причины поломки, если реальной поломки небыло? Но придется, т.к. догадаться о том, что сбой теста произошел из-за ошибки чтения диска не так то просто.
Хуже всего, что может случится так, что тесты будут давать false-positive результат, из-за которого все больше и больше они будут игнорироваться разработчиками.
Если вам необходим случайный набор входных данных для тестов, то сгенерируйте его, для этого, кстати, есть специальные утилиты.
Но это уже будут не автоматические тесты, о которых я говорю, а стресс-тесты.
Этот тип тестирования так-же необходим, но возможно не в процессе ночных сборок.
>>Мысль номер два
Как это противоречит с тем, что я писал?
Естественно нужно исправлять ошибку, если тесты не проходят.
Я считаю, что проект должен быть всегда в исправном состоянии и все тесты до единого должны проходить успешно при ночных сборках, а также в процессе сборки релизной версии.
Я на прошлой работе такой диск под кэш для squid'а использовал.
Использую такой диск уже третий год. Единственное, что меня сильно доставало — предупреждения системы. Потом дошли руки, я их отключил.
Статья использует факты бывшие верными для винчестеров лет 10 назад, сейчас всё не так. И, как правильно заметил scrab, в современном винчестере если видны нескомпенсированные им самим бэдблоки, то такой винчестер отправляется скорее всего в морг (за исключением редких случаев известного фабричного брака, типа, апгрейда прошивки, пропайки платы). Более того, попытки читать/писать такой неисправный винчестер уже сами по себе ухудшают ситуацию, лучше использовать оставшееся время жизни на бэкап.
А для проверки можно воспользоваться широко известной в узких кругах утилитой Victoria.
А для проверки можно воспользоваться широко известной в узких кругах утилитой Victoria.
утилитой Victoria
или MHDD ;)
для запуска длинного SMART самотеста (со сканированием всей поверхности диска и обновлением служебной статистики) достаточно и штатного smartmontools (конкретно команда smartctl --test=long)
А можно пояснить, что изменилось по сравнению с «лет 10 назад»? Речь же вроде шла о HDD, а не о SSD с remap… Каким образом контроллер диска должен скомпенсировать блоки? Правда, интересно :)
Только вот работает он на порядок (если не более) дольше и сильно подвисает, как и основной режим, при столкновении с сильно поврежденными областями диска.
А хочется, чтобы существовала утилита, которая шустро пробегает по диску, анализируя его адаптивным образом
Откройте для себя ddrescue, которая в т.ч. может и составлять списки дефектных блоков.
Да и вообще утилита крайне полезна для максимального вытягивание данных с дисков, уже содержащих те или иные дефекты поверхности, главное подобрать оптимальный режим работы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрый поиск неповрежденных областей на умирающем жестком диске