Данные в данном случае стоят не много. Здесь другая ситуация. Сам по себе контроллер - дополнительные грабли при восстановлении, случись что с аппаратной начинкой. Система построена так, что нужно её быстро запустить и она не должна вызывать коллизий. До текущего момента мне было не известно о проблемах рассинхронизации md. Придётся пересматривать этот момент.
Но не ReiserFS. Она работает несколько быстрее, как раз и за счет того, что пологается на аппаратную начинку. Здесь даже не от ФС зависит. Несколько странно было бы после каждой записи делать Verify.
В штатном случае своп использоваться НЕ должен. Если он настолько активно используется - это значит, что системе не хватает ресурсов и их НАДО добавить. Т.е. использование свопа сигнализирует о проблеме.
В данном случае - даже MySQL не пишет несколько раз в секунду на диск данные в один и тот же сектор в течении продолжительного времени. Специфика MySQL такова, что он в основном производит много чтений, которые как раз забиваются в кеш ОС. А отложенной записи опять же на правильно настроенной системе нет.
Софт-рейд в данном случае убьет производительность к чертям. Собственно, поэтому и не делает. Я так понимаю, этот момент там организован хуже даже чем в Fake-RAID.---------- Добавлено в 09:08 ---------- Предыдущее сообщение было в 08:26 ----------Итак, на вполне работающем массиве наблюдается mismatch. При перезагрузке данные разные на дисках, но всё же синхронизируется у меня с первого рейда. Я так и не смог симулировать ситуацию, когда рейд будет запущен после резета в синхронизированном состоянии. А вот замечательный фэйл: виртуальная машина после резета на ext2 полностью разрушила свою ФС. не смотря ни на какие рейды... 70% данных находятся в lost+found. Очень занимательная ситуация... Активно скриптом вставлялись данные в MySQL, ФС была примонтирована с Defaults. Много думаю...
какая разница? Метаданные - те же часто меняющиеся данные. И не важно, файл это или нет.
Я разве сказал, что дело только в дма? Кстати, это не является проблемой в обычном случае. От обрыва питания рейд спасать и не должен, а представить проблему в другом случае мне пока не удается. Свопа в правильно настроенной системе быть не должно. Как и прерванной записи. А если приложение по несколько раз в секунду пишет один и тот же файл - с ним что-то не то...
нет. Об этом написано в мане. нет.
вы предлагаете держать тонну контроллеров и запчасти к ним? Или что делать с этим барахлом, когда через 5 лет выйдет из строя контроллер? закупать еще 2 новых? та не вопрос. Прошу понять, что под надежностью понимается не только вероятность выхода из строя детальки, но так же вероятность проблем любых.
дма-запись на винты. В разный момент времени там могут быть разные данные. Т.е. при работе массива они там на винтах не синхронны, например это своп, частоизменяемый файл, прерванная запись. собственно, это и есть в цитате. При потере питания это может быть фатально...---------- Добавлено в 00:29 ---------- Предыдущее сообщение было в 00:28 ----------netwind, да ничего я от вас не хочу. Нужны вы мне. Можете спать идти.
при репэйр - с первого диска. а вообще вот вам ля размышлений. собсна картина с рейзером чуть яснее:
Suppose I memory-map a file and often modify the mapped memory.
The system will at some point decide to write that block of the file
to the device. It will send a request to raid1, which will send one
request each to two different devices. They will each DMA the data
out of that memory to the controller at different times so they could
quite possibly get different data (if I changed the mapped memory
between those two DMA request). So the data on the two drives in a
mirror can easily be different. If a ‘check’ happens at exactly this
time it will notice.
Normally that block will be written out again (as it is still ‘dirty’)
and again and again if necessary as long as I keep writing to the
memory. Once I stop writing to the memory (e.g. close the file,
unmount the filesystem) a final write will be made with the same data
going to both devices. During this time we will never read that block
from the filesystem, so the filesystem will never be able to see any
difference between the two devices in a raid1.
So: if you are actively writing to a file while ‘check’ is running on
a raid1, it could show up as a difference in mismatch_cnt. But you
have to get the timing just right (or wrong).
I think it is possible in the above scenario to truncate the file
while a write is underway but with new data in memory. If you do
this, the system might not write out that last ‘new’ data, so the last
write to the particular block on storage may have written different
data to the two different drives, and this difference will not be
corrected by the filesystem e.g on unmount. Note that the inconsistent
data will never be read by the filesystem (the file has been
truncated, remember) so there is no risk of data corruption.
In this case the difference could remain for some time until later
when a ‘check’ or ‘repair’ notices it.---------- Добавлено в 00:14 ---------- Предыдущее сообщение было в 00:12 ----------
если система физически выключена по причине сбоя - как раз так и надо. выдергаем из одной и пихаем в другую.
Это не тот вариант. Не надежно по другим параметрам.
Случайным ли?
netwind, Блок питания сгорит? Контроллер на мамке умрёт? И т.п.? А система рассчитана так, что диск выдергивается немедленно и втыкается в другой аналогичный аппарат. И дисков там в RAID1 аж 4 штуки стоят... И система эта используется совсем не для размещения сайтов. Долгий простой может и жизни стоить. Хватит давать глупые советы. Мне сейчас придётся пачку экспериментов поставить, только и всего.
GreenBee, Отдельный сервер или ФТП для резервирования данных надо держать. Желательно у другого прова. Ну, а случившееся - форс-мажор, если вы не поняли.
P.S> Паркинг - золотой партнёр майкрософта и по величине входят в пятерку крупнейших. Так что прежде чем кидаться говном в этого хостера - следует поразмыслить.
netwind, А если питание пропадёт? Тогда как?
