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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
