Упражнения с бревном (FreeBSD raid5 performance)

Бурное обсуждение моей предыдущей заметки про аппаратный RAID заставило меня потратить немножко времени в выходные на изучение software raid5 в FreeBSD (других подопытных ОС не оказалось).

Приборы и материалы

FreeBSD 7.1-PRERELEASE - i386, Core2Duo 1.86, 2GB RAM, 3 диска Western Digital WD7500AAKS (750Gb).

Диски я извлек из рабочей станции, там они показывали 140MB/sec на чтение и 120-125 на запись будучи прицеплеными к Areca ARC-1120 в режиме RAID5 под WinXP/Vista.

GEOM RAID5 все еще не входит в комплект FreeBSD, поэтому использовались две из трех имеющихся внешних реализаций: GEOM RAID5 TNG и GEOM RAID5 PP. Забегая вперед скажу, что существенной разницы в производительности я не увидел.

Помимо этого, я посмотрел на производительность RAID0 (GEOM stripe).

Тестирование проводилось на чтении-записи длинных файлов т.к. меня интересуют именно они. На коротких операциях всё может быть иначе, все "короткие" нагрузки настолько разные, что требуют тестирования по месту.

RAID0

RAID0 (gstripe) делался с интерливом 128 килобайт, файловая система - с размером блока 32 килобайта.

Скорость записи получилась равной 198 MB/sec (40-гигабайтный файл т.е. гарантированно мимо всех кэшей). Скорость чтения с настройками по-умолчанию - всего 80MB/sec. Разгадка очень простая: в одном блоке "интерлива" помещаются 4 блока файловой системы, на трех дисках - соответственно 12. После подъема vfs.read_max до 24 скорость чтения выросла до 180 MB/sec и осталась там при дальнейшем увеличении read_max до 32, 64 и 72.

Несколько странно, что скорость чтения оказалась меньше скорости записи, перемерял много раз, результат один.

RAID5

graid5 -s 131072 data /dev/ad1 /dev/ad2 /dev/ad3

Полное построение RAID5 на трех 750Gb дисках занимает 5.5 часов, что быстрее 3Ware но значительно медленнее Areca и ATTO, жить можно.

После настроек из форума производительность получилась: 128MB/sec на запись и 113-116MB/sec на чтение. Таким образом, запись примерно как у аппаратного контроллера, а чтение - процентов на 20 медленнее. Эта производительность практически одинакова и у -TNG и у -PP версий geom_raid5. Цена такой скорости - примерно 400Mb kernel memory, что в сегодняшних условиях вполне можно себе позволить.

Проблемы

Чтобы ощутить проблемы, достаточно нажать reset на сервере в процессе записи. Нет, файловая система не разваливается, но после загрузки массив начинает ребилдиться. По его собственным прогнозам, ребилд займет чуть меньше суток. В процессе ребилда нагрузка на дисковую систему небольшая и тестовые чтение-запись идут с той же скоростью, что и без ребилда, однако что случится, если в этом состоянии еще и отвалится один из дисков - предугадать трудно.

Понятно, что ребилд - обязательное свойство после неаккуратной перезагрузки, ибо записать состояние дисков кроме как на эти диски - некуда и оно все и должно стать durty. Но неприятно.

К сожалению, "ребилд после ресета" убивает идею симбиоза graid5 и gjournal - восстановление после ресета в любом случае получается долгим. При этом, gjournal на отдельный диск - убъет производительность (ибо запись на массив быстрее), а на тот же массив - тоже убъет (из-за лишних seeks). Несмотря на это, конечно буду пробовать.

Comments

Леха, мегабайт сокращается как MB (http://en.wikipedia.org/wiki/Megabyte), а не как Mb, что означает мегабит. То же самое верно для остальных байтов/битов.

Вот зануда!

Я использую -eff в продакшн. Во-первых, можно ценой замедления "нормальной" работы ускорить ребилд примерно в четверо:

kern.geom.raid5.veri_nice=0
kern.geom.raid5.veri_fac=1000

Во-вторых, я настраивал -eff (-pp хуже на чтение, чем -eff настраиваетс,Я автор в недоуменни, но эффект подтверждает) на твои скорости при вдвое более медленных дисках ;-)
Примерно так:

kern.geom.raid5.maxmem=80000000
kern.geom.raid5.maxwql=200
kern.geom.raid5.wdt=5

В третьих, оно у меня уже разваливалось аппаратно. Всё восстановило. Дважды-фейл -- да, скорее всего умрёт.

А как аппаратные массивы БЕЗ БАТАРЕЙКИ решают проблему ресета, а? Вроде как он тоже обязан начать ребилдится в такой ситуации.

Да, gjournal пробовал, не понравилось.

Вопрос про разваливание (лень доставать и выдергивать диск, хотя надо конечно попробовать) такой - вот оно сейчас уже
raid5/data REBUILDING CALM ad1 (130544697344 / 17% (p:7003))

Если я пойду и из CALM вытащу диск - то что будет?

А с RAID без батарейки ситуация очень простая - то, что synced на диск - уже там (мимо кэша). То что не synced - ситуация в точности такая, как с одним диском - что-то могло недозаписаться, состояние этого блока неопределенное, нужно fsck. Ну вот разве только "блок" получается побольше.

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

Во всяком случае, я себе это именно так понимаю. И никогда нажатие ресета/питания не ведет к полному ребилду.

если я пойду и из CALM вытащу диск - то что будет?
DEGRADED будет, по идее. Хотя... Может у тебя там и правда лажа? Надо в VMWare поэкспериментировать, это несложно. Я повожусь на неделе.

А с RAID без батарейки ситуация очень простая - то, что synced на диск - уже там (мимо кэша). То что не synced - ситуация в точности такая, как с одним диском - что-то могло недозаписаться, состояние этого блока неопределенное, нужно fsck. Ну вот разве только "блок" получается побольше.
Я не очень понимаю, как аппаратный RAID гарантирует, что все диски synced. Даже если он пишет одновременно в разные каналы. Т.е. ьез батарейки -- почему он не ребилдится, если его срубили в момент записи? Он же не может гарантировать правильной чексуммы как минимум в той точке, в которую он сейчас писал! Чем он тут отличается от софтового RAID5? Какая разница, где рассчёт чексуммы идёт -- на CPU или на сопроцессоре на карте? Не вижу разницы.

Контроллер - не может гарантировать, что тот блок который писался в момент ресета - дописался.

Ну так и отдельный диск не может этого гарантировать - те блоки, которые писались (а их туда насыпали много - tagged queueing) - какие-то записались, а какие-то нет. Но мы же диск не ресинкаем (ибо не с чем).

А вот блоки, про которые диск сказал что записаны - те записаны. И у контроллера должна быть такая же семантика.
От того, что появилась прокладка с гигабайтом кэша - ничего не меняется.

Для меня, на самом деле, весь этот софтверный ресинк удивителен. Если семантика fsync() работает (файл лежит на диске с гарантией после него) - то нахрена ребилд?

Контроллер - не может гарантировать, что тот блок который писался в момент ресета - дописался.
graid5 -- тоже, так?


Вот! Только потому что не с чем! В этом-то всё и дело!

А вот блоки, про которые диск сказал что записаны - те записаны. И у контроллера должна быть такая же семантика.
Вот только контроллер не может (физически) обеспечить то, что на всех дисках засинкается одно число блоков -- полные страйпы. Не сделать ему атомарно это. Никак. Потому что диски могут запросы по-разному переупорядочить. И, значит, ему таки НАДО синкать чексуммы -- он не может гарантировать, что оно "записано или не записано", может оказатся записано только пол-страйпа, даже если он отправил свои куски в каждый диск.

Для меня, на самом деле, весь этот софтверный ресинк удивителен. Если семантика fsync() работает (файл лежит на диске с гарантией после него) - то нахрена ребилд?
Для меня удивительно отсутсиве ребилда у аппаратных контроллеров.

Потому что если мы ребутнулись В ПРОЦЕССЕ fsync()'а, то мы не можем гарантировать целостности массива (точно так же, как на одном диске -- целостность файловой системы). Не важно, аппаратные мы или софтверные. Важно что мы попросили записать новые данные и новую чексумму и унас нет НИКАКИХ знаний о том, какая часть была записана, а какая -- нет. Значит надо проверяться. И, заметим, если graid5 в момент ребута был CALM, то он не будет ребилдится, всё честно.

Тут у хардварного контроллера есть такое приемущество, что на плате можнт быть напаяна какая-нибудь FeRAM или вовсе flash, и он там может вести журнал, выдерживающий перезагрузку, и чекать не всё а только те страйпы, которые он на запись отправил а подтверждения от ВСЕХ дисков не получил. Но делают ли так какие-нибудь контролелры -- я не знаю. Но даже если делают -- НЕ ЧЕКАТЬ ВООБЩЕ НИЧЕГО -- это диверсия.

1. Контроллер естественно знает (диск ему сказал) какие блоки реально записались. И только для этих блоков он вернет операционной системе "записано, завершай свой fsync()" (собственно, поэтому синхронная запись на RAID такая медленная).

2.Если у нас что-то записалось, а что-то нет (контрольная сумма расходится с данными других дисков) - мы это не можем порекаверить, ибо не знаем что правильно (в ситуации когда диск вернул ошибку записи или чтения - тогда знаем). В этом смысле ресинхронизация просто не имеет смысла.

Возможно, я что-то не понимаю в жизни и есть какая-то алгоритмика, которая пункт 2 позволяет пофиксить, но из обших соображений - нету.

софтовому раиду точно так же диск всё может сказать.

Возможно, я что-то не понимаю в жизни и есть какая-то алгоритмика, которая пункт 2 позволяет пофиксить, но из обших соображений - нету.
Судя по всему все считают, что чексумма по определению не верна, а если данные побились -- то это отловится на уровне выше... Короче, RAID5 хранит свою целостность, а не целостность данных :)

А, соврал про диски, я удмал ты всё на тех же SAS'ах пробуешь. У меня WD5000AAKS, т.е. та же линейка и полостность (в отличие от 320 и 640, которые заметно быстрее 500 и 750-ых).
Так что да, ровно так оно и работает. У меня -- C2D E4500, 2Gb памяти тоже. Но дисков 5.

Кстати, самая жуть -- это bgfsck + ребилд. У меня машина колом встаёт.

полостност
плотность

Ну и мне кажется, так рассуждая, gjournal вообще должен убивать производительность :)

P.S. Блин, дёшево же ты ATTO взял... правда мне фигли толку -- FreeBSD их не поддерживает :(

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

б) всякий продакшн. Веб-сайт или поисковик или база данных и т.п. Ситуация, когда пропадание питания ведет к многочасовому fsck и/или ребилду - категорически неприемлема. Питание имеет тенденцию пропадать целыми стойками (и залами), подниматься после такого сутки - очень не хочется. Поднимать veri_nice - еще больше убивать перформанс.

От fsck спасает (в теории) журнал. Пока не пробовал (вообще никогда), наверное завтра вечером попробую, как раз поребилдится, 8 часов осталось (veri_nice поднял, может и за 4 справится).
А от ребилда - похоже ничего не спасает (кроме настояшего контроллера)

б) всякий продакшн. Веб-сайт или поисковик или база данных и т.п.
Понимаешь, такой продакшн у меня вовсе не ассоциируется с отсуствием контроллера с батарейкой баксов хотя бы з 700 или от скольки они там начинаются. А это на корню решает пробелму ребилдов. Или нет?
Т.е. нам нужен и массив и с контрольной суммой и с минимальным простоем -- а 15-20 тыяч рублей мы пожидились заплатить 1 раз? Офигеть.

От fsck спасает (в теории) журнал. Пока не пробовал (вообще никогда), наверное завтра вечером попробую
Будет очень интересно почитать. Ведь журнал можно добавить к существующей FS, так?
Я пробовал журнал, но одновременно с этим я пробовал и 64KiB-блоки и словил дедлок. Думал, что от журнала, оказалось что от сочетания FS blocks в 16KiB и 64KiB в одной системе на разных FS (known bug FreeBSD, увы) -- но от журнала отказался и так к нему и не вернулся.

как раз поребилдится, 8 часов осталось (veri_nice поднял, может и за 4 справится).
Он (graid5) ещё и параноик смешной. У меня в момент ребилда шла работа -- капали торренты по NFS на массив. Так в логе было через строчку апдейты статуса по двм причинам -- собюственно апдейт и потому что оно переходило в HOT. Прогнозы разоичались ровнов вдове. Т.е. строчка -- прогноз на 900 минут, следующая -- 450, следующая 895, следующая 440, и так далее. Правдой оказалось меньшее число. Но нагрузка там была капельная, факт.

Проблема с батарейкой в том, что в 1U-корпус ее часто некуда запихать. Просто нет места.

А вообще, сейчас 1U корпус с процессорами и прочими потрохами обойдется небось штуки в полторы-две (без дисков), а то и меньше. И диски еще в 700. На этом фоне 500-600 за 4-портовый контроллер - заметно.

Т.е. у меня цель скорее исследовательская - посмотреть что за жилец этот raid5 (до того был ZFS, на 32-битной FreeBSD - не жилец). Потому что сама по себе идея - благородная "зачем платить больше".

Кстати о корпусах! Ты не исследовал вопрос корпуса домой под RAID? У меня сейчас чифтек, там 6xHDD внутри, поперёк, с вентиляторами тоже поперёк (от боковй стенки к боковой). Всё бы ничего, но что-то хочется хот-свапа, т.е. внешних корзин. На 6 дисков. Не в стойку... Хм. Ничего такого не видел? И что бы винты хоть как-то обдувались...

А зачем дома хотсвап? Дома скорее нужна амортизированная подвеска дисков
(кстати, у меня все залмановские "охладители" потеряли по второй ножке за год, поубивав бы)

Вообще - вопрос не исследовал. У меня дурацкий термалтейковский корпус "для медиацентра", он выглядит прикольно, но на самом деле далек от оптимальности. Но пока всерьез решать проблему лень.

Скорее не хотсвап, а нормальные Backplanes и каналы под кабеля, а это обычно делают с хотсвапом. А то под 6 дисков провода с турдом лезут и местами опасно гнутся...

Ну я не знаю, у меня в WS 7 дисков, да еще с этими идиотскими SAS-кабелями для бедных (без backplane) - там же разъемы питания обычные, а не SATA получаются. Выглядит мерзко, но стяжки рулят.

Вообще, у Интела есть корзина с SAS-экспандером на 4 диска, надо смотреть, не встанет ли она в обычные 5" отсеки.

Еще вот такое бывает: http://www.satadrives.com/qudrsaiihddq.html

Во, нашел штуку, которая рулит:
http://www.netlab.ru/descr_price_ID.asp?id=95500

3 диска в 2 5" отсека.

Ого! И недорого. И В Питере есть в розице. Спасибо. Буду думать.

Еще есть Promise 4600 - 4 диска в 3 5", но дороже раза в два.

Вообще, на этот 3-TO-2 есть смысл посмотреть, мне есть куда его деть.

У меня как раз 4x5", так что 3-2-2 отлично встанет дважды. 6 дисков. Прекрасно.
Правда, с охлждением будет похуже -- воздух вентиляторы будут тянуть сквозь 5"-салазки, там много не натянешь...

Я вот загулял в вебе на эту тему и мне очень понравилось вот это вот:

http://www.chenbro.com/corporatesite/products_detail.php?serno=100

Оно, конечно, интересно сугубо теоретически т.к. 2.5" диски, но блин 26x26x14 сантиметров и 5 дисков, из них 4 - hot swap. Через пару лет можно будет брать. Внешний питальник все портит, конечно.

> Полное построение RAID5 на трех 750Gb дисках занимает 5.5 ча
Linux Software RAID быстрее (ре-)билдит, как мы с <lj user=blacklion> выяснили. :-)

Это я же. Алексов блог меня не-ЖЖ-авторизует :)

Re: > Полное построение RAID5 на трех 750Gb дисках занимает 5.5
А что у LSR со скоростями чтения-записи?

Я из свежего нашел вот это: http://www.linux.com/feature/140734
и там вывод довольно однозначный, hardware рулит. Для geom_raid5 разница в пользу железки тоже есть, но не такая большая.

> А что у LSR со скоростями чтения-записи?
Ну, про чтение я уже говорил: http://alextutubalin.livejournal.com/116813.html?thread=693837#t693837

Re: > А что у LSR со скоростями чтения-записи?
Мне очень трудно сравнивать апельсины (block device) с яблоками (file на FS)

Поэтому куда интереснее
dd if=/dev/zero of=file bs=большой count=так, чтобы гигов 40 получилось

Ну и наоборот, прочитать записанный file обратно.

> Поэтому куда интереснее
А будет с финиками тогда сравнение. :-) У меня лично LVM-2 на LSR. Был бы чистый, ненужный раздел именно с LSR, сравнили бы запись. А так, в р-не 75.5 MB/s в среднем, если XFS / LVM-2 / LSR. :-)

P. S. chunksize мелковат 128 KiB. Так что хрен его знает. Может, если руки дойдут, переделаю на побольше. :-)

Re: > Поэтому куда интереснее
Ну вот у меня те же 70-80 были на ZFS (RAIDZ) на трех сигейтовских 500-ках. Что мне кажется маловато, т.е. все эти упражнения с volume management не должны бы так убивать перформанс.

Да, кстати, забыл сказать
у меня тогда на дисках был ещё Write Cache выключен. Впрочем, на последовательные операции большого значения это оказывать не должно.

> Несколько странно, что скорость чтения оказалась мен
http://poige.livejournal.com/258717.html

это, кстати, на RAID-контре было дело.

Re: > Несколько странно, что скорость чтения оказалась м
И это для исправных дисков - ненормально.

> "ребилд после ресета" убивает идею симбиоза graid5 и gjournal
А в LSR, по-моему, собирались подобие журнала сделать чтобы не весь объём перефигачивать, если что .

Я задумался ровно об этом к geom-raid5, но надо понять что можно дёшево вставить в компьютер быстрое и энергонезависимое. Пока решения не видно.

Журнал на другом диске или самом массиве убъёт производительность записи в ноль.

> Цена такой скорости - примерно 400Mb kernel memory
Хренассе. У LSR и с этим всё значительно приятнее! :-)

Re: > Цена такой скорости - примерно 400Mb kernel memory
Я особо не тюнил - на фоне ZFS это все копейки (под ZFS было 800).

Там можно очередью записи играться, но мне проще было списать готовые настройки.

Ну вот, хотел тебе как раз на выходных написать результаты мощного тестирования разных софтрейдов под фрей и под линуксом, а ты решил сам попробовать :).
При правильном тюнинге у меня raid5 из четырех дисков под freebsd показывал 180 метров на чтение и 120 метров на запись. Диски барракуда SATA 1Tb трехблиновые 7200.11, контроллер nForce MCP630, процессор - старый одноведерный кал от AMD.
Ребилд происходит часа за три-четыре.
Но я от этого решения отказался, и вот почему - несмотря на все ритуальные танцы с ATA, которые происходят в ядре за последний год, с хот-плагом на nForce полная, окончательная и тотальная задница. То есть - 6.4 тупо виснет при изьятии диска, а если не повисла при изьятии - повиснет при вставлении :). У семерки с этим несколько лучше - то есть при изьятии диска она виснет с меньшей вероятностью, но начинает срать в dmesg про interrupt storm on irq 11. Проверялось все вплоть до stable, включая разнообразные комбинации с включенным и выключенным ACPI и разными режимами набортного контроллера, битьем в бубен atacontrol и пр.
Самое обидное при этом не то, что оно виснет - а то, что вновь всунутый диск оно не видит без рестарта системы и никакой atacontrol помочь не в силах.
Под линуксом все пучком, что обидно :)

А на запись так медленно потому что процессор слабый?

Отчасти, т.к. увеличение очереди на запись помогает, но не сверхсупермегасильно - все равно оно задумывается в процессе записи. Процессор двухлетней давности АМД - это я себе файлопомойку дома неспешно кромсаю в запиленном корпусе микро-атх.
Я думаю что больше влияет тот факт, что на nForce принудительно выключается NCQ, т.к. необходимые для его корректной работы пассы в дровах отсутствуют.

С корпусами жопа, т.е. в нормальном минимальном конструктиве ничего нету за вменяемые деньги (есть корпуса за 300 баксов под mini-ITX с четырьмя хардами хот-свап - но это изврат).
Я по таковой причине взял в руки дрель и болгарку и запилил обычный говноящик от инвин с тремя внешними дырами под 5,25" под размер по вертикали платы микро-атх, развернув питальник вертикально над процом. Получился такой кирпичик :).
В это дело я всадил корзинку вот такую, тока такую брать не советую, т.к. у моей креза с индикаторами активности на хардах (иллюминация как на новогодней елке) и жутко шумный вентилятор нестандартного форм-фактора 80x80x20. Вентилятор я ампутировал и присобачил нормальный снаружи, а вот с иллюминацией особо ничего не поделаешь.
После разочарования в софтрейдах под FreeBSD нахожусь в раздумьях - поставить на нее OpenFiler или купить нормальный контроллер и остаться с подпиленным FreeNAS, или забить на проблемы с hot-plug :).
Думаю на новогодние праздники таки доделать этого зверя до полностью товарного состояния - тогда выложу картинки с выставки.

Корзинка интересная, но блин SATA. Там внутри SAS-овский хотсвап или SATA-only (со шпеньком)? Вентилятор можно 80x15 вбубенить.

А что за ITX с 4 SATA? Я видел chenbro, мне очень нравится, но у меня вот сейчас в домашнем сервере аж 3 ethernet, это требует наведения порядка. Может после нового года займусь....

Насчет сас - вечером посмотрю, как-то не акцентировал внимания, хотя разбирал до основания чтобы снять вентиль. Вентиль 80x15 с рамкой хрен найдешь в продаже.
Корпус был имхо тот самый Chenbro ES34069, но у меня предубеждение относительно mini-ITX в таком интимном деле. Нормальный рейд туда хрен впихнешь, имхо - не физически, конечно, а с точки зрения взаимопонимания экзотических мамок и хитровыделанных контроллеров.

Блин, тяжело в деревне без нагана. Там русским языком написано - корзина SAS/SATA :), прям по ссылке что я запостил.

Да я ушел гулять по комедианту - выяснилось что там есть и SATA-корзины и SAS/SATA. Как можно обеспечить первое - для меня загадка, отчего и спросил.

Но, конечно, чешутся руки на ITX, удержаться сложно.... Если там гигабит и оно умеет этот гигабит выдуть, то точно не удержусь!

Насчет выдут гигабит - с коре2 думаю выдует, с атомом или с виа не верится. Две проблемы - стоимость всей радости (спецящик + мама) получается неоправданно велика, за разницу я в свой попиленный гробик засуну не то что саташный, а и сас контроллер; грабли с поддержкой рейда в единственном кое-где наличествующем слоту pcie x16 лежат широко и желания быть по ним первопроходцем не возникает.
Ну и тонкий момент - от внешнего питала 120 ватт завести четыре харда, аппаратный рейд и C2D - как бы оно не рвануло с оранжевым сиянием..

да, ты прав, но 26x26x14

mATX-кейс в который влезет 4 диска в hotswap (т.е. с тремя 5" бэями в одной стопке) - это что-то типа 35x45x18. Ну или кубики вроде lanbox lite (30x43x23).

При том, что меня в первую очередь нервирует глубина и уложиться по ней в 35 сантиметров очень хочется, просто сил нет как

А что такого в mini-ITX экзотического? Есть интеловские матеря, скорее всего полностью рабочие.

А ты посмотри на страдания кар-писишников вокруг этой темы. Да, они рабочие в пределах заявленной функциональности. Однако если вопрос с засовыванием pcie 8x контроллера в десктопную мать уже вызывает некий элемент острых ощущений и жути из серии "а с новыми биосами не пашет", то с mini-itx попасть на порядок легче имхо. Просто потому, что узок круг тех революционеров, что пихали арековские или триварные карты в mini-itx..

Э... а говорим mini-ITX, подразумеваем Атом? От обычного C2D будет греться?

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

Ну мой запиленный ящик 27x46x18. Если бы на Марсе были города (в смысле если бы на платах mATX не росли в районе свободного торца разные высокие компоненты типа разьема 24 пин или слотов DIMM) - то можно было бы и в длину мальца запилить. Беда в том, что они там таки растут, и максимум что там можно выпилить - это сантиметров пять, т.к. у сатовых корзин толстая жопа. Поскольку мне была актуальнее высота (все хозяйство живет на кухне на уютной этажерке между холодильником и шкафом), возможный выигрыш пяти сантиметров по глубине не стоил геммороя с запилом.

Сделал graid5 по статье с opennet (здесь недостаточно информации, а ссылки на http://www.fluffles.net/forum/ мёртвые, он помер год назад). Так вот, у меня 4 терабайтника Western Digital ребилдятся целиком за 3,5 часа. При этом в момент ребилда на (уже созданный) рейд (с файловой системой) можно писать/читать (!). Но ребилдинг при этом меняется с CALM, на HOT, а спустя какое-то время возвращается в CALM. Также после перезагрузки (командой reboot, без аварий) часто происходит ребилдинг. Причём сначала HOT, а затем CALM. Вопрос: что это CALM и HOT Rebuilding вообще, вы разобрались? Чем они отличаются?