Re: Soft-RAID mismatch_cnt != 0
Christian Schneider <chschneider@nurfuerspam.de> wrote:
> ich benutze unter etch'n'half ein Soft-RAID 1. Beim letzten checkarray
> ist mir aufgefallen, dass der mismatch_cnt 256 betrug. Ein Vergleich
> der einzelnen Dateien in dem betroffenen Dateisystem brachte keinen
> Unterschied. Mir erschien es kein Zufall zu sein, dass ich zuvor heftig
> kompiliert habe und die Platten-IO-Last recht hoch war.
Ja, das ist bei RAID1 relativ normal (rein vom Bauchgefuehl her hat es
sich in neueren Kernel-Versionen etwas gebessert, aber ich hab mir noch
nicht die Zeit genommen, das tatsaechlich zu belegen).
Ursache ist nach meinen Beobachtungen i.d.R. - wie Du ja auch schon
vermutest - hohe I/O-Last, genauer: eine hohe inode-Fluktuation.
Bei RAID1 werden Daten aus einer Speicherseite auf zwei oder mehr
Disks geschrieben. Aus Effizienzgruenden macht(e?) md dabei keine Kopie
der Seite, sodass es passieren kann, dass die Seite modifiziert und
damit dirty markiert wird, auf eine der Disks geschrieben wird, wieder
modifiziert wird und dann erst auf die naechste Disk geschrieben und
clean markiert wird. Fuer Daten ist das ein eher ungewoehnliches
Usage-Pattern. Ich hatte das mal vor einiger Zeit auf der md-Liste
diskutiert, der Fall wurde aber als zu selten angesehen, um sich darum
zu kuemmern. Ich persoenlich halte das gerade im Falle inode-basierter
Dateisysteme unter hoher inode-Fluktuation fuer einen durchaus haeufigen
Fall und beobachte(te) es auch haeufiger - und zwar ausschliesslich in
inode-Arealen. Allerdings ist dabei bei mir nie was schlimmes passiert,
insofern hab ich es als zwar unangenehm, aber eher ungefaehrlich
eingestuft.
regards
Mario
--
Doing it right is no excuse for not meeting the schedule.
-- Plant Manager, Delphi Corporation
Reply to: