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" <[email protected]>
> *An:* "Linux-User-Group Dresden" <[email protected]>
> *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 - [email protected]
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>
>
> _______________________________________________
> Lug-dd maillist - [email protected]
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>
--
Mit freundlichen Grüßen
Rico Körner
netbreaker.de IT-Service
Radeberger Str. 95-G
01099 Dresden
Tel: 0177/8381099
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
