Периодический самозапуск проверки дисков

Это было в debian тыщу лет. Да и не только в нем, что тоже написали выше.

Не врите так.

Мнение "большинства" - в технике иррелевантно. Тем более, непонятно какого большинства, взятого с потолка.

Нормально аргументировать что? Появление нечитаемых секторов на дисках? Ну загляните в спецификации, там все указано.

Спешите видеть: netwind против бородатых программистов, реализующих всякие read patrol вообще и авторов md raid в частности :)

Ну вот, видите. Все как доктор прописал.

Кстати, подобные даунтаймы на пустом месте (если нет ошибок) - запросто можно избежать (LVM).

ну попутал немного дебиан с центосом. и там и там тухляк.

в каких именно спецификациях и кто рекомендует проверку массива раз в месяц и почему именно раз в месяц?

Вообще, дебиану уже тыща лет, а о проверке задумались только в 2007 с выходом etch. В centos/rhel еще более затянули.

Как же оно раньше все работало ?

Мне совершенно очевидно, что политика дистрибутива задает мнение большинства его пользователей.

В спецификациях дисков (всякие BER, UBE, URE).

Что касается частоты - не думаю, что есть универсальные рекоммендации. Некоторые контроллеры запускают подобные проверки практически неприрывно (напр, вот: http://support.dell.com/support/edocs/software/svradmin/5.1/en/omss_ug/html/cntkpatm.html).

Вы бы задумались не о том, что для проверки сделали стандартный кронтаб - а о том, когда сама возможность проверки появилась (2005? позже?). Кому положено - помнили и использовали все это куда раньше, чем сделали умолчанием в каком-либо дистрибутиве.

С чего вы взяли, что оно "работало"? Вы ждете, что вам сразу волшебная фея прилетит и расскажет, что данные в каком-то секторе вообще "тю-тю".

Кроме того, раньше диски были меньше.

Далеко не все пользователи mdadm в дебиан вообще знают о существовании проверки. Я уж не говорю про том, чтобы "иметь мнение".

Для энтерпрайзнутого RHEL (и его нищебродских копий) - ситуация, наверное, еще хуже.

ну как бы md raid был задолго до 2007. саму возможность запускать проверку приделали в 2.6.16 - март 2006. А сам raid включили в ядро где-то в 1996 году в 1.3.69.

т.е. 10 лет вопрос о необходимости сверки массива не был насущным и разработчиков не волновал.

учитывая это, разве не очевидно, что большинству на эту проверку наплевать?

за эти 10 лет стали полагаться на рейд намного больше, раньше все же понимали, что рейд - не средство резервирования.

---------- Добавлено 22.01.2012 в 23:12 ----------

нормально - когда LA около 4 единиц на одно ядро процессора. В среднем. Но всё очень индивидуально, следует помнить, что LA имеет лишь косвенное отношение к нагрузке на сервер.

Т.е. сразу и попал в debian, верно? Вместе с кронтабом.

Де-факто, md raid был страховкой от отказа диска целиком. Видимо, люди полагались на большее, а тут появились SATA (помните, "ZFS любит SATA!"), терабайтные диски - отсюда и проверки, а сейчас вот badblocks.

Все закономерно.

Нет.

Реально это произошло только через год, когда вышел etch. Это ж дебиан. Так у них всегда.

Не закономерно, а странно. Бедблоки всю дорогу были и на маленьких и на больших дисках.

Наоборот, чем меньше диски тем более ненапряжно их проверять. А вот на терабайтниках проверка затянется и выльется в неприятные проблемы в понедельник утром.

Реально на современных дисках больше данных можно потерять. Требования к отказоустойчивости растут...

Вы у андрейки научились :) Я помолчу, когда "это произошло" в RHEL - и что, теперь генту ставить?

Но на больших они стали "фичей".

Скорости были другие.

Вам уже писали, что проблема не в проверке. Не выливается, ну и что я делаю не так, объясните?

не эксплуатируете системы на пределе возможностей.

по остальным пунктам полностью не согласен.