Beiträge von astielau

astielau · 19. Januar 2010

Hi,

ich hab eine Qnap TS-219P (3.1.1 Build 0815T) mit zwei WDC WD10EADS Caviar Green 1TB, gekauft am 18.12.09, konfiguriert als RAID1.

Vorgestern ist das NAS beim Booten in den Raid-Recovery-Mode gegangen (Schalter blinkt rot/grün abwechselnd) und war während dieser Zeit auch nicht übers Netz ansprechbar (das scheint Absicht zu sein, geht aber so nicht aus der Doku hervor, wäre gut, wenn das drin steht, sonst macht man sich noch mehr als nötig nen Kopf um seine Daten).

Nach ewigen Zeiten des Versuchs, das Raid wieder zusammenzupuzzeln, hab ich dann wieder Netzwerkzugriff, die eine (zweite) Platte ist am Gehäuse rot gekennzeichnet, und über die Webadministrationsoberfläche gar nicht mehr sichtbar.

Im Log stehen die Einträge:

Code

2010-01-18 	12:22:35	System	System started.2010-01-18	12:23:20	System      [Mirror Disk Volume: Drive 1 2] Drive 2 has been added into Volume 1.2010-01-18	12:27:18	System	Drive 2 might have bad blocks. Please do "Bad Blocks Scan" on it.2010-01-18	12:28:25	System	[Mirror Disk Volume: Drive 1 2] Start rebuilding.2010-01-18	15:34:36	System	[Mirror Disk Volume: Drive 1 2] Rebuilding skipped.2010-01-18	15:34:49	System	[Mirror Disk Volume: Drive 1 2] Drive 2 has been removed.2010-01-18	15:34:49	System	[Mirror Disk Volume: Drive 1 2] RAID device is in degraded mode.2010-01-18	15:34:50	System	[Mirror Disk Volume: Drive 1 2] Drive 2 failed.

Syslog finde ich nicht, aber dmesg schreibt (leicht gekürzt um vielfach gleiche Einträge):

Code

raid1: sdb: unrecoverable I/O read error for block 553088
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sdb1
 disk 1, wo:1, o:1, dev:sda1
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sdb1
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sdb1
 disk 1, wo:1, o:1, dev:sda1
md: recovery of RAID array md9
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
md: using 128k window, over a total of 530048 blocks.
active port 0 :139
active port 1 :445
active port 2 :20
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
md: md0 stopped.
md: bind<sdb3>
md: bind<sda3>
md: kicking non-fresh sdb3 from array!
md: unbind<sdb3>
md: export_rdev(sdb3)
raid1: raid set md0 active with 1 out of 2 mirrors
md0: bitmap initialized from disk: read 15/15 pages, set 198 bits, status: 0
created bitmap (233 pages) for device md0
md: bind<sdb3>
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda3
 disk 1, wo:1, o:1, dev:sdb3
md: delaying recovery of md0 until md9 has finished (they share one or more physical units)
kjournald starting.  Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
eth0: link down
eth0: started
eth0: link up, full duplex, speed 100 Mbps
eth0: link down
eth0: stopped
eth0: started
eth0: link up, full duplex, speed 100 Mbps
active port 0 :139
active port 1 :445
active port 2 :20
iSCSI Enterprise Target Software - version 0.4.17
iscsi_trgt: Registered io type fileio
iscsi_trgt: Registered io type blockio
iscsi_trgt: Registered io type nullio
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
rule type=2, num=0
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
Loading iSCSI transport class v2.0-870.
iscsi: registered transport (tcp)
md: md9: recovery done.
md: recovery of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
md: Recovering started: md0
md: using 128k window, over a total of 975193600 blocks.
RAID1 conf printout:
 --- wd:2 rd:2
 disk 0, wo:0, o:1, dev:sdb1
 disk 1, wo:0, o:1, dev:sda1
sd 0:0:0:0: scsi: Device offlined - not ready after error recovery
(wird 6 mal wiederholt)
sd 0:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sdb, sector 655925764
raid1: Disk failure on sdb3, disabling device. 
        Operation continuing on 1 devices
sd 0:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sdb, sector 655925892
(wird 29mal für verschiedene Sektoren wiederholt)
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
md: super_written gets error=-5, uptodate=0
raid1: Disk failure on sdb4, disabling device. 
        Operation continuing on 1 devices
sd 0:0:0:0: rejecting I/O to offline device
md: md0: recovery done.
md: recovery skipped: md0 
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
md: super_written gets error=-5, uptodate=0
raid1: Disk failure on sdb1, disabling device. 
        Operation continuing on 1 devices
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda4
 disk 1, wo:1, o:0, dev:sdb4
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda4
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:1, o:0, dev:sdb1
 disk 1, wo:0, o:1, dev:sda1
RAID1 conf printout:
 --- wd:1 rd:2
 disk 1, wo:0, o:1, dev:sda1
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda3
 disk 1, wo:1, o:0, dev:sdb3
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda3
active port 0 :139
active port 1 :445
active port 2 :20
md: unbind<sdb1>
md: export_rdev(sdb1)
md: unbind<sdb4>
md: export_rdev(sdb4)
md: unbind<sdb3>
md: export_rdev(sdb3)
active port 0 :139
active port 1 :445
active port 2 :20
 Wake up disk 1 immediately.
(naja, das ist jetzt normalbetrieb, kommt auch 20 Mal)

Alles anzeigen

Meine Frage:
Macht es Sinn, die zweite Platte noch mal in einen anderen Rechner zu basteln oder z.B. per shell auf dem NAS dem ganzen mit mdadm&Co beizugehen?

Auf dem System selbst sehe ich beide Platten (cat /proc/partitions zeigt sda und sdb-Partitionen), kann aber nicht mit fdisk oder hdparm auf /dev/sdb zugreifen.
Das Problem ist, daß ich, solange die Platte im NAS noch als grün (an der Gerätefront) markiert ist und sie beim Recovern sinnvoll blinkt, nicht an die Shell ran komme, um etwas mehr Diagnose zu betreiben.

Das dmesg-Log sieht so aus, als würde das System die Platte aktiv abhängen.

Oder ist die Platte wirklich hin, weitere Mühe, das näher rauszufinden (ich hab nicht direkt einen Rechner zur Verfügung, der SATA könnte, alles SCSI hier) und ich schicke die einfach zum Händler und warte auf Ersatz?

Tipps wilkommen,
Aleks