Onderwerp: MD raid probleem.

Moest vandaag in de logfiles van een van de servers zijn en kwam toen op 9 april dit heeeeeeel vaak tegen.

Apr 9 03:45:28 server21 kernel: md: delaying data-check of md0 until md3 has finished (they share one or more physical units)
Apr 9 03:45:29 server21 kernel: md: delaying data-check of md0 until md3 has finished (they share one or more physical units)
Apr 9 03:45:29 server21 kernel: md: delaying data-check of md0 until md3 has finished (they share one or more physical units)
Apr 9 03:45:30 server21 kernel: md: delaying data-check of md0 until md3 has finished (they share one or more physical units)

Dit was nog niet eerder gebeurt dus ben even verder gaan spitten omdat dit volgens wat zoekresultaten veroorzaakt zou kunnen worden door slecht geconfigureerde raid.
Daar is echter niet aan verandert en werd standaard bij de installatie gedaan. Toch maar eens kijken en dan zie ik toch dingen die ik bij de andere servers niet zie, zoals deze bitmaps en chunks:

Personalities : [raid1]
md2 : active raid1 sda3[0] sdb3[1]
1073741632 blocks super 1.0 [2/2] [UU]
bitmap: 4/8 pages [16KB], 65536KB chunk

md3 : active raid1 sda5[0] sdb5[1]
1839216960 blocks super 1.0 [2/2] [UU]
bitmap: 0/14 pages [0KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
16777088 blocks super 1.0 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
524224 blocks [2/2] [UU]

Dus maar even verder zoeken en dan zie ik dit in de /etc/mdam.conf

DEVICE partitions
MAILADDR root
ARRAY /dev/md/0 metadata=1.0 UUID=914f56a1:0b065921:590d9ff6:3132999b name=rescue:0
ARRAY /dev/md1 UUID=9c92f3aa:09482aef:776c2c25:004bd7b2
ARRAY /dev/md/2 metadata=1.0 UUID=87b6f8ae:2bd745a4:4f1612f6:615f89ed name=rescue:2
ARRAY /dev/md/3 metadata=1.0 UUID=8f615898:b4b8fa11:52ef2cf1:a398bbad name=rescue:3

Zie de tweede regel. Bij de andere servers stat hier netjes /dev/md/1 en niet /dev/md1. Ook staat er name=rescue:1 achter.
Ik weet niet of dit er mee te maken kan hebben, maar vreemd lijkt het me wel en het zou leuk zijn als dit te fixen was.

Ter grotere info, misschien is hier nog iets uit te halen?
Deze valt mij wel op.
/dev/sda4 135830 364802 1839219160 f W95 Ext'd (LBA)
kom ik bij een oudere server ook tegen dus weet niet of dit een probleem is.

Zie hier onder voor wat grotere info.

Code:

Disk /dev/loop0: 5120 MB, 5120000000 bytes
255 heads, 63 sectors/track, 622 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x9256584f

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        2089    16777216+  fd  Linux raid autodetect
/dev/sdb2            2089        2155      524288+  fd  Linux raid autodetect
/dev/sdb3            2155      135829  1073741824+  fd  Linux raid autodetect
/dev/sdb4          135830      364802  1839219160    f  W95 Ext'd (LBA)
/dev/sdb5          135830      364802  1839217112+  fd  Linux raid autodetect

Disk /dev/sda: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x3ba10e74

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        2089    16777216+  fd  Linux raid autodetect
/dev/sda2            2089        2155      524288+  fd  Linux raid autodetect
/dev/sda3            2155      135829  1073741824+  fd  Linux raid autodetect
/dev/sda4          135830      364802  1839219160    f  W95 Ext'd (LBA)
/dev/sda5          135830      364802  1839217112+  fd  Linux raid autodetect

Disk /dev/md1: 536 MB, 536805376 bytes
2 heads, 4 sectors/track, 131056 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/md0: 17.2 GB, 17179738112 bytes
2 heads, 4 sectors/track, 4194272 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md3: 1883.4 GB, 1883358167040 bytes
2 heads, 4 sectors/track, 459804240 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/md2: 1099.5 GB, 1099511431168 bytes
2 heads, 4 sectors/track, 268435408 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Is hier inderdaad iets mis en zo ja, hoe kan ik 't repareren?

Eerst zien dat je een backup hebt, dan pas sleutelen !

Ja die backup is er, dat is het probleem niet.
Ik vraag me alleen af of hier wel of niet sprake is van een probleem en of dat met die md1 naar md/1 gefixed moet worden.

als het goed is moet md/1 gewoon een symlink zijn naar md1. Dat zal het probleem niet zijn. Misschien de 1 net met een iets ander commando aangemaakt?

Not sure omdat ik geen md raid gebruik maar md/1 was volgens mij de oude notatie.

check met mdadm --details /dev/md0 (en voor 1,2,3) eens of dat er gezond uit ziet.

Geen ander commando, is een standaard installatie door het datacentrum via het controlepaneel gekozen. Vandaar dat ik het ook vreemd vind dat die vermelding op die andere servers wel correct staat aangegeven, terwijl die de laatst geinstalleerde server is.
Als md/1 een oude notatie is zou dit het dan wel verklaren, maar dan zouden die andere twee regeltjes ook niet uit md/x moeten bestaan want die zijn van hetzelfde moment lijkt me.
Maarja, als het geen kwaad kan op deze manier dan kan ik er beter af blijven.

Er staat overigens een s teveel, het correcte commando is mdadm --detail (zonder s) anders herkent ie hem niet, maar dat terzijde.

Code:

mdadm --detail /dev/md0 
/dev/md0:
        Version : 1.0
  Creation Time : Mon Sep 19 09:18:24 2016
     Raid Level : raid1
     Array Size : 16777088 (16.00 GiB 17.18 GB)
  Used Dev Size : 16777088 (16.00 GiB 17.18 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sun Apr  9 08:02:56 2017
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:0
           UUID : 914f56a1:0b065921:590d9ff6:3132999b
         Events : 107

mdadm --detail /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Mon Sep 19 09:18:30 2016
     Raid Level : raid1
     Array Size : 524224 (511.94 MiB 536.81 MB)
  Used Dev Size : 524224 (511.94 MiB 536.81 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Mon Apr 10 17:10:58 2017
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 9c92f3aa:09482aef:776c2c25:004bd7b2
         Events : 0.111

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2


mdadm --detail /dev/md2
/dev/md2:
        Version : 1.0
  Creation Time : Mon Sep 19 09:18:32 2016
     Raid Level : raid1
     Array Size : 1073741632 (1024.00 GiB 1099.51 GB)
  Used Dev Size : 1073741632 (1024.00 GiB 1099.51 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Apr 11 16:52:48 2017
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:2
           UUID : 87b6f8ae:2bd745a4:4f1612f6:615f89ed
         Events : 44533

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3


mdadm --detail /dev/md3
/dev/md3:
        Version : 1.0
  Creation Time : Mon Sep 19 09:18:32 2016
     Raid Level : raid1
     Array Size : 1839216960 (1754.01 GiB 1883.36 GB)
  Used Dev Size : 1839216960 (1754.01 GiB 1883.36 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Apr 11 16:32:21 2017
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:3
           UUID : 8f615898:b4b8fa11:52ef2cf1:a398bbad
         Events : 8863

    Number   Major   Minor   RaidDevice State
       0       8        5        0      active sync   /dev/sda5
       1       8       21        1      active sync   /dev/sdb5

Hmmz... misschien toch niets aan de hand? Ziet er goed uit, of kijk ik nu verkeerd? Zie overal netjes "clean" en "superblock persistent". Geen failed devices. Als die "Preferred Minor" verder niks uit maakt tenminste.

Dan blijft het toch vreemd dat er zoveel van die "md: delaying data-check of md0 until md3 has finished" regels in de log kwamen, toch?

Dit al gelezen?

https://utcc.utoronto.ca/~cks/space/...idMessageFlood

Nu wel. Maar als ik het goed begrijp denkt hij dat het een bug is en heeft hij de MAXCONCURRENT instelling verandert om die berichten te doen verdwijnen.
Het zegt mij nog niet of ik nu een probleem heb of niet.

Op de andere servers heb ik dit ook maar slechts heel kort, als volgt:

Mar 19 01:00:07 server16 kernel: md: delaying data-check of md0 until md1 has finished (they share one or more physical units)
Mar 19 01:00:07 server16 kernel: md: delaying data-check of md0 until md1 has finished (they share one or more physical units)
Mar 19 01:00:08 server16 kernel: md: md1: data-check done.
Mar 19 01:00:08 server16 kernel: md: data-check of RAID array md0
Mar 19 01:00:08 server16 kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Mar 19 01:00:08 server16 kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
Mar 19 01:00:08 server16 kernel: md: using 128k window, over a total of 16777088k.

En dan nog eens voor md1 en md2, maar niet zo'n hele waslijst aan regels.

Ik wil die raid-check setting wel naar 1 zetten als het verder geen kwaad kan.

nou, de melding is geen ramp eigenlijk omdat die wel klopt eigenlijk. omdat je md arrays op dezelfde disks hebt, is ie voor zijn volgende array check aan het wachten totdat ie exclusief access heeft voor de verify.
De 'bug' is het flooden, wat dan weer niet echt een bug is maar niet gethrottled wordt door syslog omdat de melding bij meer dan 2 md arrays afwisselt.

Die melding komt dan doordat er voor elke array een verify start. Leuk als je md array telkens geheel 2 disks hebben (bij raid 1) maar bij gesharede diskd krijg je dit.

Die max zetten op 1 zou ik doen als als je de raid arrays op 2 fysieke disks hebt. Dan heb je de melding niet meer zo vaak en de doorlooptijd van de verify zal niet gek veel langer zijn.

Ah gelukkig, dan hoef ik niet ongerust te zijn. Ik was al een beetje bang omdat er achter die md1 geen name=rescue1 stond, dat die misschien niet mee zou gaan in de mirror of zoiets, dus geen rescue.

Die melding komt dan doordat er voor elke array een verify start. Leuk als je md array telkens geheel 2 disks hebben (bij raid 1) maar bij gesharede diskd krijg je dit.

We hebben in elk systeem twee echt fysieke disks er in zitten die op Raid 1 draaien. Als er eentje stuk gaat kunnen we die verwisselen en dan weer de raid opnieuw opbouwen. Even los van de backups die er uiteraard ook zijn.

Op die ene server heb ik die max nu op 1 gezet. Dan zal het wat rustiger worden in de logs.

Bedankt voor de hulp en antwoorden!

Ja, 2 disks is 1 md raid set is ok, maar je hebt 4 raid sets op 2 fysieke disks. Niet elke mdX op 2 ándere fysieke disks.

Oh op die manier. Ja klopt, heb ook geen idee waarom dat zo gedaan is door dat installatiescript.
De oudste heeft er ook 4 en de middelste heeft er 3.
Zal er volgende keer eens op letten of daar ook iets van te configureren is bij het datacenter. Zien of ik er 2 van kan maken als dat beter is.

Nou, het maakt niet of je meerdere mdX hebt. Eigenlijk is dat organisatorisch zelfs niet slecht hoor en beter dan alles op 1 partitie dumpen. Kijk, zo'n verify gaat echt niet sneller met meerdere concurrent processen, tenzij die verify commando's ook concurrent door raidarrays op standalone disks(sets) afgehandeld kunnen worden.
Stel je hebt md0 op diskA+B en md1 op diskC+D dan zou je md0 en md1 tegelijk kunnen checken. Staan md0 + md1 beide op DiskA+B dan heeft een concurrent check waarschijnlijk geen zin omdat ze beiden dan op 50% van de resources draaien, dus wacht mdadm daar gewoon op.

Maar dit heb ik ook maar bij elkaar gegoogled, ik gebruik het zelf niet. Dat heb ik al afgeleerd. Een HW raid van 500 euro kost je per maand op 5 jaar afschrijving amper een 10tje incl. BBU en een lading cache. Ik zelf zou als hoster liever geen server met software raid opleveren om een tientje meer winst te hebben, maar ja... als het unmanaged is dan is dat wel een opening naar veel meer winst als de boel kapot gaat

Heb ik toch weer iets bij geleerd. Ben niet zo heel erg goed thuis in raid, behalve dat ik een beetje weet wat het doet, maar dat heb je vast al gemerkt.
Gaat mij er maar om dat als er 1 disk stuk gaat het makkelijk te vervangen is en verder draaien.
Persoonlijk zou ik ook eerder kiezen voor een HW raid, maar ik ben slechts een reseller die wel onderhoud, update en beveiliging doet, vind ik gewoon leuk om te doen, maar heb niks over aanschaf te zeggen, geef wel advies, maar dat wordt (hw raid) niet altijd opgevolgd.
Of er op die gehuurde machines ook een HW raid te krijgen is zou ik zo niet weten, misschien wel. Maar wij zijn slechts kleintjes met 3 servers en dan is het al weer op, soms tijdelijk 4 servers als het goed gaat. Inderdaad unmanaged, daar ben ik dan voor en het datacentrum wisselt harddisks als het nodig is.
Mogen best tevreden zijn in 9 jaar tijd is er 3x een disk stuk gegaan, netjes vervangen, ook weer netjes opgebouwd zonder problemen, backups niet nodig gehad.

Dat was anders bij een kennis die ik ook hielp, die had volgens zijn hoster wel hardware raid maar volgens mij niet want toen daar iets mis ging met de schijf was het klooien en meneer had ook slechts een oude backup... LoL, daar heeft ie wel van geleerd.

Ach, wij hebben vroeger eens gehad dat een DC met hun handson bij het wisselen van een disk uit een raid5 systeem, de verkeerde disk trok om te vervangen. Dan is de lol ook snel voorbij, maar je weet dat shit happens. Dus altijd eerst je backupsysteem in orde. Welke raid je dan gebruikt is ook deels een kwestie van budget en persoonlijke voorkeur.

Ja shit happens, moet wel altijd serienr. doorgeven van de disk voordat ze hem er uit jassen dus er wordt wel goed naar gekeken, maar da's geen garantie dat er niets gebeurt, da's zonder meer waar.
Backups zijn gelukkig wel in orde, dus dat scheelt weer inderdaad.