Spontaan resync'en Linux-RAID1 array.

[Josefien]

Mijn thuisserver die dienst doet als Samba-DC en DNS/DHCP-server draait op Debian Linux 4.0. Voor dataopslag zitten er twee 250GB harde schijven in (1 Maxtor, 1 WD). Ze zitten in een Linux-RAID1-array. Echter... met een uptime van 37 dagen is dit al de tweede keer dat hij spontaan de RAID-array begint te resync'en. Dmesg geeft alleen het volgende:

code:

md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 243167808 blocks.

De schijven zijn beide nog in goede conditie. Maar waarom moet hij spontaan gaan resync'en? Mijn webserver met 2x20GB doet dit niet... Is er misschien iets mis met het systeem?

Ter aanvulling: "cat /proc/mdstat" levert alleen het volgende op;

code:

Personalities : [raid1]
md0 : active raid1 hde2[0] hdg2[1]
      243167808 blocks [2/2] [UU]
      [=>...................]  resync =  5.6% (13775552/243167808) finish=122.2min speed=31269K/sec

unused devices: <none>

Er wordt niks vertelt over dat er een schijf gefaald is, maar toch begint hij te resync'en. Wat zou het probleem kunnen zijn?

[Aike]

Staat er ook niks in je syslog?

[berties]

Wanneer is deze resync begonnen? Welke tijd en dag?
(zie daarvoor bijvoorbeeld je syslog; "kernel: md:" of "mdadm:")

[ph0t0nix]

Wat zeggen de smartmontools over de errors op je HDDs?
Welk moederbord gebruik je?

[Cruise Control]

Er is niets mis met je hardware.

Dit doet debian 4.0 standaard iedere eerste zondag van de maand om 01:06. Kijk maar in /etc/cron.d/mdadm.

[ Voor 48% gewijzigd door Cruise Control op 04-07-2007 18:47 ]

[Josefien]

kern.log zegt alleen het volgende:

code:

Jun  3 01:06:02 server1 kernel: md: syncing RAID array md0
Jun  3 01:06:02 server1 kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Jun  3 01:06:02 server1 kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jun  3 01:06:02 server1 kernel: md: using 128k window, over a total of 243167808 blocks.
Jun  3 03:16:58 server1 kernel: md: md0: sync done.
Jun  3 03:16:58 server1 kernel: RAID1 conf printout:
Jun  3 03:16:58 server1 kernel:  --- wd:2 rd:2
Jun  3 03:16:58 server1 kernel:  disk 0, wo:0, o:1, dev:hde2
Jun  3 03:16:58 server1 kernel:  disk 1, wo:0, o:1, dev:hdg2

Het klopt dus inderdaad dat hij elke eerste zondag van de maand, om 1:06, de md-arrays synchroniseerd. Alleen is het wel vreemd dat hij de sync op 1 juli niet heeft gelogd...

Ik heb /etc/cron.d/mdadm bekeken en inderdaad staat erin dat hij de arrays automatisch synchroniseert. Echter... is het schadelijk voor mijn data? Ik bedoel... stel dat tijdens het proces één schijf gaat falen, wat gebeurt er dan met mijn data? Is het dan allemaal verloren?

[ Voor 5% gewijzigd door Josefien op 22-03-2017 22:25 ]

[Verwijderd]

kienwaiwong schreef op donderdag 05 juli 2007 @ 00:57:
Ik heb /etc/cron.d/mdadm bekeken en inderdaad staat erin dat hij de arrays automatisch synchroniseert. Echter... is het schadelijk voor mijn data? Ik bedoel... stel dat tijdens het proces één schijf gaat falen, wat gebeurt er dan met mijn data? Is het dan allemaal verloren?

Nee, natuurlijk niet! Dat is juist de grap van RAID1!

Voordat je dit soort vragen stelt is het altijd handig om even in de gratis bijgeleverde documentatie te kijken, zie /usr/share/doc/mdadm en dan met name het bestand README.checkarray

Voor de luie gebruikers:

checkarray notes
================

checkarray will run parity checks across all your redundant arrays. By
default, it is configured to run on the first Sunday of each month, at 01:06
in the morning. This is realised by asking cron to wake up every Sunday with
/etc/cron.d/mdadm, but then only running the script when the day of the month
is less than or equal to 7. See #380425.

'check' is a read-only operation, even though the kernel logs may suggest
otherwise (e.g. /proc/mdstat and several kernel messages will mention
"resync"). Please also see question 21 of the FAQ.

If, however, while reading, a read error occurs, the check will trigger the
normal response to read errors which is to generate the 'correct' data and try
to write that out - so it is possible that a 'check' will trigger a write.
However in the absence of read errors it is read-only.

You can cancel a running array check with the -x option to checkarray.

-- martin f. krafft <[e-mail]> Mon, 08 Jan 2007 02:07:19 +0100

$Id: README.checkarray 295 2007-01-08 01:07:42Z madduck $