форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Открытые системы на сервере (Файловые системы, диски / Linux)
Изначальное сообщение		[ Отслеживать ]

"Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
Сообщение от MarvinFS (ok) on 14-Янв-10, 13:15
Коллеги, сделал 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 2009 CUround, MarvinFS
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
Сообщение от MarvinFS (ok) on 14-Янв-10, 16:12
>[ 8.701813] md: md127: raid array is not clean -- starting background или если вопрос поставить по другому: независимо от необходимости и выполнения ресинка рэйда, останется ли консистентной база данных на журналируемой EXT4 при некорректном выключении питания?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
	Сообщение от su4p on 14-Янв-10, 23:56
	> >>[ 8.701813] md: md127: raid array is not clean -- starting background > >или если вопрос поставить по другому: > >независимо от необходимости и выполнения ресинка рэйда, останется ли консистентной база данных >на журналируемой EXT4 при некорректном выключении питания? Это скорее вопрос к разработчикам ext4 относится )) RAID работает ниже уровня файловой системы, и спасает только от последствий отказа оборудования, но не от сбоя файловой системы, неверных действий пользователя и т.д. Если не хочешь ребилда при каждом сбое питания, и несколько большей надежности, попробуй отключи кеширование записи для самих дисков на которых рэйд расположен. Быстродействие записи конечно при этом несколько снизится. А вообще ты не написал что за рейд, аппаратный, софт, и т.д.?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
	Сообщение от MarvinFS (ok) on 15-Янв-10, 05:38
	>ты не написал что за рейд, аппаратный, софт, и т.д.? написал, это софтовый стандартный линукс рэйд на устройстве /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 мегабайт в секунду, что для меня более чем достаточно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
Сообщение от 1 (??) on 02-Апр-10, 10:55
я тоже интересуюсь надёжностью софтовых vs аппаратных рейдов, и вот что накопал: http://linas.org/linux/raid.html т.е. от отключения питания именно софтовый рейд не спасает (аппаратный с батарейкой спасает), нужны доп меры в виде журналов и проверок контрольных сумм, у ext4 есть эти меры: - барьеры, (надо проверить/ещё почитать, но по идее должны гарантировать) гарантируют последовательность что сначала запишется журнал, а потом будет обновление данных и затем комит транзакции - журналирование данных, либо мы оставляем старые данные либо новые, если в журнале есть все новые данные и не дописали часть поверх старых то допишем при проверке журнала, если не успели записать в журнал, то старые данные не тронуты и считаются вполне правильными и не испорченными. это противодействие отключению во время записи данных (и соответственно их порче), у аппаратных для этого есть батарейка к кешу. - проверка контрольной суммы журнала транзакций, думаю это и так понятно - журнал должен быть исправным для доверия ему. мне кажется вполне достаточно их применять для того чтобы быть уверенным в целостности данных именно на софтовом рейде. от перестроения рейда не спасут, но данные с оч высокой вероятностью будут правильными. надо почитать ещё про барьеры в ext4. у самого есть мысли (как) написать прототип софтового рейда с повышенной устойчивостью к сбоям. осталось заняться
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Debian: EXT4 journal и md RAID10 перестраивает зачем?"		+/–
	Сообщение от 1 (??) on 02-Апр-10, 10:58
	дополню: вообще проверки контрольных сумм при чтении конечно тоже не хватает, но пока вроде ни одна из фс (кроме zfs, других случаев не знаю) этого не реализует.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема