Hallo Liste,
ich habe nach einem Festplattentausch ein Problem mit der Synchronisation des RAIDs, weil jetzt auch auf der 2. Platte ein Fehler aufgetaucht ist.
~# cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda3[2](S) sdb3[1] 1451496768 blocks [2/1] [_U]
Die Partition /dev/sda3 auf der neuen Platte ist nach dem Sync nicht eingebunden, sondern als Spare (S) aufgeführt.
~# mdadm -D /dev/md2 /dev/md2: Version : 0.90 Creation Time : Tue May 4 19:09:57 2010 Raid Level : raid1 Array Size : 1451496768 (1384.26 GiB 1486.33 GB) Used Dev Size : 1451496768 (1384.26 GiB 1486.33 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 2 Persistence : Superblock is persistent
Update Time : Tue Sep 24 11:28:14 2013 State : clean, degraded Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1
UUID : 67084b3c:2d4cdd43:776c2c25:004bd7b2 Events : 0.1768518
Number Major Minor RaidDevice State 0 0 0 0 removed 1 8 19 1 active sync /dev/sdb3
2 8 3 - spare /dev/sda3
Ursache ist ein Lesefehler auf /dev/sdb3 beim Sync. Ob der fehlerhafte Sektor überhaupt benutzt ist, weiß ich auch (noch) nicht.
An sich ist dieser Current_Pending_Sector (siehe smartctl) noch kein großes Problem, beim Schreibversuch darauf wird dieser ja verlegt, solange noch Reservesektoren (laut Reallocated_Sector_Ct) frei sind, was hier der Fall ist. Solange aber nur lesend darauf zugegriffen wird, bleibt der Fehler bestehen.
smartctl-Auszug: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 098 098 036 Pre-fail Always - 95 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 36961 1754701143
Das ist derzeitig der einzige Anhaltspunkt, welcher Sektor betroffen ist. /dev/md2 ist ein PV im LVM. Darin stecken natürlich mehrere LVs. Es ist auch noch freier Platz vorhanden. Allerdings ist nicht erkennbar, welches LV und welcher Block darin betroffen ist, um anschließend mit dd gezielt darauf loszugehen.
Wobei einige LVs auch wieder virtuelle HDDs für KVM sind und sich die Analyse dann ggf. in die VM verlagert.
Mir fällt nur ein etwas mühseliger Weg ein: Den freien Speicher in der VG einem LV zuweisen, alle Sektoren mit dd überschreiben, um hier defekte Sektoren auszuschließen bzw. damit umzulagern. Danach das LV wieder löschen und Ersatz-LVs für die anderen Partitionen anzulegen, den Inhalt zu kopieren, neues LV mounten und das alte LV wieder mit dd überschreiben.
Hat jemand einen besseren Ansatz?
Gruß Rico
Hier waren hilfreiche Infos zu finden: http://smartmontools.sourceforge.net/badblockhowto.html#lvm
1754701143 (aus smartctl) - 27278370 (PartStart aus fdisk -lu) =1727422773 Offset in der Part / 8192 (PE size 4M, LBA-Blocksize 512) = 210867,03772
lvdisplay --maps | grep 'Physical extents' | sort ... Physical extents 203264 to 207359 Physical extents 243020 to 268619 ...
Der Block liegt also ziemlich sicher dazwischen in einem freien Bereich. So groß ist der Offset von RAID/LVM nicht. Einem neuen LV den freien Speicher zugewiesen und mit dd überschrieben, das reichte in dem Falle schon. Da der betroffene freie Block der 1. dem LV zugewiesene war und der Fehlerhafte damit bei ca. 10,8 GB lag, hab ich einfach mal drauflosgeschrieben, aber vorzeitig wieder abgebrochen, da die I/O-Last dabei extrem anstieg (Load > 30). Da aber schon > 20GB geschrieben wurden, war der Fehler bei smartctl -t short verschwunden. Beim nächsten Mal wird wohl etwas genauer gezielt mit dd.
Jetzt läuft noch ein -t long und dann der nächste Sync.
Rico
Am 24.09.2013 13:00, schrieb Daniel Leidert:
Hi,
Ich erinnere mich, dazu vor kurzem zwei Howtos gelesen zu haben. Die sollten mit Google leicht auffindbar sein und evtl. Antworten auf deine letzten Fragen enthalten. Wenn du sie nicht findest, sag Bescheid, dann schaue ich später mal in meine Linksammlung.
VG Daniel
*Gesendet:* Dienstag, 24. September 2013 um 12:25 Uhr *Von:* "Rico Koerner" rico@netbreaker.de *An:* "Linux-User-Group Dresden" lug-dd@mailman.schlittermann.de *Betreff:* RAID-Resync-Fehler durch Current_Pending_Sector Hallo Liste,
ich habe nach einem Festplattentausch ein Problem mit der Synchronisation des RAIDs, weil jetzt auch auf der 2. Platte ein Fehler aufgetaucht ist.
~# cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda3[2](S) sdb3[1] 1451496768 blocks [2/1] [_U]
Die Partition /dev/sda3 auf der neuen Platte ist nach dem Sync nicht eingebunden, sondern als Spare (S) aufgeführt.
~# mdadm -D /dev/md2 /dev/md2: Version : 0.90 Creation Time : Tue May 4 19:09:57 2010 Raid Level : raid1 Array Size : 1451496768 (1384.26 GiB 1486.33 GB) Used Dev Size : 1451496768 (1384.26 GiB 1486.33 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 2 Persistence : Superblock is persistent
Update Time : Tue Sep 24 11:28:14 2013 State : clean, degraded Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1
UUID : 67084b3c:2d4cdd43:776c2c25:004bd7b2 Events : 0.1768518
Number Major Minor RaidDevice State 0 0 0 0 removed 1 8 19 1 active sync /dev/sdb3
2 8 3 - spare /dev/sda3
Ursache ist ein Lesefehler auf /dev/sdb3 beim Sync. Ob der fehlerhafte Sektor überhaupt benutzt ist, weiß ich auch (noch) nicht.
An sich ist dieser Current_Pending_Sector (siehe smartctl) noch kein großes Problem, beim Schreibversuch darauf wird dieser ja verlegt, solange noch Reservesektoren (laut Reallocated_Sector_Ct) frei sind, was hier der Fall ist. Solange aber nur lesend darauf zugegriffen wird, bleibt der Fehler bestehen.
smartctl-Auszug: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 098 098 036 Pre-fail Always - 95 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 36961 1754701143
Das ist derzeitig der einzige Anhaltspunkt, welcher Sektor betroffen ist. /dev/md2 ist ein PV im LVM. Darin stecken natürlich mehrere LVs. Es ist auch noch freier Platz vorhanden. Allerdings ist nicht erkennbar, welches LV und welcher Block darin betroffen ist, um anschließend mit dd gezielt darauf loszugehen.
Wobei einige LVs auch wieder virtuelle HDDs für KVM sind und sich die Analyse dann ggf. in die VM verlagert.
Mir fällt nur ein etwas mühseliger Weg ein: Den freien Speicher in der VG einem LV zuweisen, alle Sektoren mit dd überschreiben, um hier defekte Sektoren auszuschließen bzw. damit umzulagern. Danach das LV wieder löschen und Ersatz-LVs für die anderen Partitionen anzulegen, den Inhalt zu kopieren, neues LV mounten und das alte LV wieder mit dd überschreiben.
Hat jemand einen besseren Ansatz?
Gruß Rico
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Am 24.09.2013 14:18, schrieb morphium:
Hi!
Am 24.09.2013 12:25, schrieb Rico Koerner:
Hat jemand einen besseren Ansatz?
Wenn dir deine Daten wichtig sind: vorher ein komplettes Backup :-)
nicht nötig, läuft schon regelmäßig. ;) und das hilft auch nicht, den Fehler zu beseitigen.
Rico
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
morphium -
Rico Koerner