11. Список пожеланий для MD и сопутствующего ПО

Bradley Ward Allen < ulmo@Q.Net> написал:

Идеи включают:

• Параметры загрузки для указания ядру какие устройства - MD устройства (без ``mdadd'')
• Сделать MD прозрачным для ``mount''/``umount'' без использования ``mdrun'' и ``mdstop''
• Интегрировать ``ckraid'' в ядро, и запускать его при необходимости

(Итак в общем, все, что я могу предложить - избавиться от утилит и поместить их в ядро; так я это вижу, это - файловая система, а не игрушка.)

• Работа с массивами, которые могут свободно пережить одновременный, или в разное время, отказ N дисков, где N - целое > 0 устанавливаемое администратором
• Лучшая обработка застывания ядра, отключения питания, и других внезапных завершений
• Не отключать целый диск, если только часть его отказала, если ошибки секторов занимают менее 50% доступа при 20 попытках различных обращений, то просто продолжаем игнорируя эти сектора этого отдельного диска.
• Плохие сектора:
  • Механизм для сохранения плохих секторов в другом месте диска.
  • Если существует обобщенный механизм для маркировки деградировавших плохих блоков, которые вышестоящие уровни файловой системы могут распознать, использовать его. Программный он или нет.
  • Возможен альтернативный механизм извещения вышестоящего уровня, что размер диска более маленький, прямо выравнивая для вышестоящего уровня сдвигать части исключенных областей диска. Это может помочь с деградированными блоками.
  • Недостаток вышеуказанных идей, сохранять маленькое (устанавливаемое администратором) количество пространства для резервирования плохих блоков (равномерно распределенное по диску?), и использовать его (как можно более близко) вместо плохих блоков, при их появлении. Конечно, это не эффективно. Более того, ядро должно вести log каждый раз при нахождении RAID массивом плохого сектора и делать это с ``crit'' уровнем предупреждения, просто дать понять администратору, что его диск содержит пылинку в себе (или соприкосновение головки с пластиной).
• Программно-переключаемые диски:

  ``запретить этот диск''

  должно блокировать, пока ядро не завершит проверки наличия данных для сбрасывания на диск при завершении (таких как завершение XOR/ECC/других коррекций ошибок), затем освободить диск от использования (чтобы его можно было вынуть и т.п.);

  ``разрешить этот диск''

  должно, при соответствии, mkraid новый диск и затем запустить его для использования для ECC или любых операций, расширяя RAID5 массив;

  ``изменить размер массива''

  должно переопределять общее чило дисков и чило избыточных дисков, и результатом должно быть изменение размера массива; без потери данных, хорошо было бы сделать это должным образом, но я потратил много времени пытаясь описать, как это должно делаться; в любом случае, необходим режим, где массив будет блокироваться ( возможно, на несколько часов (ядро должно заносить что-то в log каждые десять секунд));

  ``разрешение диска при сохранении данных''

  это должно сохранить данные на диске как есть и перемещать их, как положено, на систему RAID5, так что ужасающее сохранение и восстановление не должно происходить каждый раз когда кто-то ``поднимает''систему RAID5 (вместо этого, может быть проще сохранять только один раздел вместо двух, он может поместится на первый как сжатый gzip-ом файл);

  ``пере-разрешение диска''

  должно быть операторской подсказкой операционной системе попробовать ранее отказавший диск (это должен быть, как я думаю, просто вызов запрещения, а потом разрешения).

Прочие идеи не из сети:

• finalrd аналог для initrd, для упрощения raid на корневой файловой системе.
• режим только-чтение для raid, чтобы упростить вышесказанное
• Помечать RAID том как чистый всякий раз когда не сделано "частичной записи". -- То есть, всякий раз нет транзакций записи, котрые были зафиксированы на одном диске, но все еще не завершены на другом диске. Добавить период "неактивности записи" (для избежания частого позиционирования головок на суперблок RAID при относительной занятости RAID тома).