Коллеги,сделал MD RAID10
из 4-х дисков Seagate 500GB SATA2
общей емкостью соответственно 1 GB
поставил туда EXT4 с журналированием.
debian:/var/log# mount
/dev/md127 on /mnt/raid10 type ext4 (rw,acl)далее проверяю отказоустойчивость
во время записи данных на массив дергаю по питанию сервер.
перегружаюсь рутовая fs выживает нормально.
а вот массивчик почему то сразу идет перестраиваться.dmesg | grep md127
[ 8.701813] md: md127: raid array is not clean -- starting background reconstruction
[ 8.715151] raid10: raid set md127 active with 4 out of 4 devices
[ 8.715243] md: resync of RAID array md127
[ 8.716257] md127: detected capacity change from 0 to 1000213577728
[ 8.716315] md127: unknown partition table
[ 12.784836] kjournald2 starting: pid 2001, dev md127:8, commit interval 5 seconds
[ 12.793917] EXT4 FS on md127, internal journal on md127:8
[ 12.891430] EXT4-fs: mounted filesystem md127 with ordered data modeя как бэ не понял, это фича или глюк? на мой взгляд журналирование на EXT4 от такого должно спасать?
оно конечно не сильно критично в плане перестроения (90 минут на PhenomII 945) но что будет например с валидностью базы данных которая предположительно будет на этом массиве в таком случае?
debian:/var/log# uname -na
Linux debian 2.6.30-bpo.2-686 #1 SMP Fri Dec 11 18:12:58 UTC 2009 i686 GNU/Linux
debian:/var/log# mdadm --version
mdadm - v3.1.1 - 19th November 2009CUround,
MarvinFS
>[ 8.701813] md: md127: raid array is not clean -- starting backgroundили если вопрос поставить по другому:
независимо от необходимости и выполнения ресинка рэйда, останется ли консистентной база данных на журналируемой EXT4 при некорректном выключении питания?
>
>>[ 8.701813] md: md127: raid array is not clean -- starting background
>
>или если вопрос поставить по другому:
>
>независимо от необходимости и выполнения ресинка рэйда, останется ли консистентной база данных
>на журналируемой EXT4 при некорректном выключении питания?Это скорее вопрос к разработчикам ext4 относится ))
RAID работает ниже уровня файловой системы, и спасает только от последствий отказа оборудования, но не от сбоя файловой системы, неверных действий пользователя и т.д. Если не хочешь ребилда при каждом сбое питания, и несколько большей надежности, попробуй отключи кеширование записи для самих дисков на которых рэйд расположен. Быстродействие записи конечно при этом несколько снизится. А вообще ты не написал что за рейд, аппаратный, софт, и т.д.?
>ты не написал что за рейд, аппаратный, софт, и т.д.?написал, это софтовый стандартный линукс рэйд на устройстве /dev/md*
а если вопрос поставить по другому:
независимо от необходимости и выполнения ресинка рэйда, останется ли консистентной база данных (например Mysql) на журналируемой EXT4 при некорректном выключении питания?
на данный момент что касается EXT4 в LENNY (я использую кернел 2.6.30)
по умолчанию включены следующие технологии обеспечивающие сохранность как блоков данных так и метаданных файловой системы
(журналирование действительно производится для метаданных, но нижеперечисленные технологии обеспечивают commit record в журнал только
после того, как все блоки были записаны в файловую систему и причем в нужной последовательности (journal checksums) )data=ordered (*)
All data are forced directly out to the main file
system prior to its metadata being committed to the
journal.
barrier=1(*)
This enables/disables the use of write barriers in
the jbd code. barrier=0 disables, barrier=1 enables.
This also requires an IO stack which can support
barriers, and if jbd gets an error on a barrier
write, it will disable again with a warning.
Write barriers enforce proper on-disk ordering
of journal commits, making volatile disk write caches
safe to use, at some performance penalty. If
your disks are battery-backed in one way or another,
disabling barriers may safely improve performance.
The mount options "barrier" and "nobarrier" can
also be used to enable or disable barriers, for
consistency with other ext4 mount options.
описание и обсуждение barrier от разработчиков
http://lwn.net/Articles/283161/
общее описание фич
http://ext4.wiki.kernel.org/index.php/Ext4...s_on_by_defaultтак что сохранность данных всё же должна обеспечиваться без запуска fsck при некорректном выключении
что касается performance impact при включении этих фич, то на мой radi10 из 4по500GB Seagate SATA2
скорость записи составляет 105 мегабайт в секунду, что для меня более чем достаточно.
я тоже интересуюсь надёжностью софтовых vs аппаратных рейдов, и вот что накопал:
http://linas.org/linux/raid.html
т.е. от отключения питания именно софтовый рейд не спасает (аппаратный с батарейкой спасает), нужны доп меры в виде журналов и проверок контрольных сумм, у ext4 есть эти меры:
- барьеры, (надо проверить/ещё почитать, но по идее должны гарантировать) гарантируют последовательность что сначала запишется журнал, а потом будет обновление данных и затем комит транзакции
- журналирование данных, либо мы оставляем старые данные либо новые, если в журнале есть все новые данные и не дописали часть поверх старых то допишем при проверке журнала, если не успели записать в журнал, то старые данные не тронуты и считаются вполне правильными и не испорченными. это противодействие отключению во время записи данных (и соответственно их порче), у аппаратных для этого есть батарейка к кешу.
- проверка контрольной суммы журнала транзакций, думаю это и так понятно - журнал должен быть исправным для доверия ему.мне кажется вполне достаточно их применять для того чтобы быть уверенным в целостности данных именно на софтовом рейде.
от перестроения рейда не спасут, но данные с оч высокой вероятностью будут правильными. надо почитать ещё про барьеры в ext4.
у самого есть мысли (как) написать прототип софтового рейда с повышенной устойчивостью к сбоям. осталось заняться
дополню:
вообще проверки контрольных сумм при чтении конечно тоже не хватает, но пока вроде ни одна из фс (кроме zfs, других случаев не знаю) этого не реализует.