• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] USB Raid Disconnect verhindern?

nbkr

Guru
Hallo,

ich habe hier zwei 1 TB Festplatten per USB an meinen Server gehängt und per mdadm ein Raid1 daraus gebaut. Es funktioniert größtenteils gut, bis zu dem Zeitpunkt an welchem der Kernel die USB Platten abhängt. Im Log steht dann folgendes:

Code:
Feb  5 03:37:20 saturn kernel: [74749.776560] usb 1-3: USB disconnect, address 3
Feb  5 03:37:20 saturn kernel: [74749.908440] usb 1-2: USB disconnect, address 2
Feb  5 03:37:27 saturn kernel: [74756.528041] usb 1-3: new high speed USB device using ehci_hcd and address 5
Feb  5 03:37:27 saturn kernel: [74756.663523] usb 1-3: configuration #1 chosen from 1 choice
Feb  5 03:37:27 saturn kernel: [74756.664844] scsi2 : SCSI emulation for USB Mass Storage devices
Feb  5 03:37:27 saturn kernel: [74756.665055] usb-storage: device found at 5 
Feb  5 03:37:27 saturn kernel: [74756.665061] usb-storage: waiting for device to settle before scanning
Feb  5 03:37:27 saturn kernel: [74756.677286] usb 1-3: New USB device found, idVendor=04fc, idProduct=0c25
Feb  5 03:37:27 saturn kernel: [74756.677305] usb 1-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Feb  5 03:37:27 saturn kernel: [74756.677311] usb 1-3: Product: USB to Serial-ATA bridge
Feb  5 03:37:27 saturn kernel: [74756.677315] usb 1-3: Manufacturer: Sunplus Technology Inc. 
Feb  5 03:37:27 saturn kernel: [74756.677319] usb 1-3: SerialNumber: SAMSUNG HDS246J1KSA07721     
Feb  5 03:37:27 saturn kernel: [74756.916043] usb 1-2: new high speed USB device using ehci_hcd and address 6
Feb  5 03:37:28 saturn kernel: [74757.051560] usb 1-2: configuration #1 chosen from 1 choice
Feb  5 03:37:28 saturn kernel: [74757.052754] scsi3 : SCSI emulation for USB Mass Storage devices

Die Platten die vorher unter /dev/sda und /dev/sdb waren, laufen dann unter /dev/sdc und /dev/sdd
Anschließend verabschiedet sich eine Platte aus dem Raid:

Code:
Feb  5 03:37:32 saturn kernel: [74761.976678] end_request: I/O error, dev sdb, sector 1927799808
Feb  5 03:37:32 saturn kernel: [74761.976678] md: super_written gets error=-5, uptodate=0
Feb  5 03:37:32 saturn kernel: [74761.976678] raid1: Disk failure on sdb1, disabling device.
Feb  5 03:37:32 saturn kernel: [74761.976678] raid1: Operation continuing on 1 devices.
Feb  5 03:37:32 saturn kernel: [74761.976678] end_request: I/O error, dev sda, sector 1927799808
Feb  5 03:37:32 saturn kernel: [74761.976678] md: super_written gets error=-5, uptodate=0
Feb  5 03:37:32 saturn kernel: [74761.976678] end_request: I/O error, dev sda, sector 1927799808
Feb  5 03:37:32 saturn kernel: [74761.976678] md: super_written gets error=-5, uptodate=0
Feb  5 03:37:32 saturn kernel: [74761.976678] RAID1 conf printout:
Feb  5 03:37:32 saturn kernel: [74761.976678]  --- wd:1 rd:2
Feb  5 03:37:32 saturn kernel: [74761.976678]  disk 0, wo:1, o:0, dev:sdb1
Feb  5 03:37:32 saturn kernel: [74761.976678]  disk 1, wo:0, o:1, dev:sda1
Feb  5 03:37:32 saturn kernel: [74761.976678] RAID1 conf printout:
Feb  5 03:37:32 saturn kernel: [74761.976678]  --- wd:1 rd:2
Feb  5 03:37:32 saturn kernel: [74761.976678]  disk 1, wo:0, o:1, dev:sda1
Feb  5 03:37:32 saturn kernel: [74761.997393] Buffer I/O error on device md0, logical block 120425590
Feb  5 03:37:32 saturn kernel: [74761.997443] lost page write due to I/O error on md0
Feb  5 03:37:32 saturn kernel: [74761.998375] Aborting journal on device md0.
Feb  5 03:37:32 saturn kernel: [74761.998510] Buffer I/O error on device md0, logical block 120422914
Feb  5 03:37:32 saturn kernel: [74761.998553] lost page write due to I/O error on md0
Feb  5 03:37:32 saturn kernel: [74762.000654] journal commit I/O error
Feb  5 03:37:32 saturn kernel: [74762.007637] Buffer I/O error on device md0, logical block 1027
Feb  5 03:37:32 saturn kernel: [74762.007686] lost page write due to I/O error on md0
Feb  5 03:37:33 saturn mdadm[3571]: Fail event detected on md device /dev/md0, component device /dev/sdb1

Reboote ich den den Server, ist das Raid wieder in Ordnung - es ist nicht mal ein Resync notwendig laut /proc/mdadm

Gibt es eine Möglichkeit den USB Disconnect zu verhindern oder dafür zu sorgen, dass die USB Platten immer nach /dev/sda und /dev/sdb gemountet werden? Gegoogelt nach dem Problem habe ich schon, konnte aber nichts finden das dem ganzen entspricht.

Danke für jeden Tipp?
 

mkossmann

Member
Die Disconnects riechen nach einen Hardwareproblem (z.B. Wackelkontakt oder Stromversorgung der Platten).
/dev/sda und /dev/sdb kannst du nicht stabil halten. Aber schau mal in /dev/disk/by_id. Diese alternativen Einträge für die Platten sollten eigentlich über den Reconnect stabil bleiben.
 
A

Anonymous

Gast
Mal abgesehen von der Schnapsidee externe USB-Platten zu einem Raid zusammenzubauen vermute ich das Problem darin, das die Platten abgehängt werden während das Raid noch läuft. Kommen diese Platten dann wieder, dann sind die alten Deviceknoten noch besetzt da ja der md-treiber dort immer noch aktiv ist. Linux hat also keine andere Möglichkeit als den Platten andere Deviceknoten zuzuordnen.

Wenn du externe Platten abhängen willst, müssen diese vorher still gelegt werden. Bei einem Raid würde das bedeuten. "umount /dev/md?" + "mdadm --stop /dev/md?" erst dann sind die Plattenresourcen frei um sie vom USB zu trennen. Wenn es aus unklaren Gründen einen Reconnect auf USB-Seite geben sollte, wird das eventuell zum Problem.

robi
 
OP
nbkr

nbkr

Guru
robi schrieb:
Mal abgesehen von der Schnapsidee externe USB-Platten zu einem Raid zusammenzubauen

Leider gibts keine andere Möglichkeit den Festplattenplatz im heimischen Netz mit der vorhandenen Hardware zu einem bezahlbaren Preis zu erweitern. Man könnte es noch ohne Raid versuchen. Das ist dann Plan B falls Plan A nicht funktionert.

Wenn du externe Platten abhängen willst, müssen diese vorher still gelegt werden. Bei einem Raid würde das bedeuten. "umount /dev/md?" + "mdadm --stop /dev/md?" erst dann sind die Plattenresourcen frei um sie vom USB zu trennen. Wenn es aus unklaren Gründen einen Reconnect auf USB-Seite geben sollte, wird das eventuell zum Problem.

Das ist es ja gerade. Ich will die Platten eben nicht abhängen. Das geschicht ohne mein zutun. Gestern ist es um 3:37 passiert, am Tag davor um 6:25. Irgendwas sorgt dafür das die Platten automatisch deaktiviert werden.

Die Disconnects riechen nach einen Hardwareproblem (z.B. Wackelkontakt oder Stromversorgung der Platten).
/dev/sda und /dev/sdb kannst du nicht stabil halten. Aber schau mal in /dev/disk/by_id. Diese alternativen Einträge für die Platten sollten eigentlich über den Reconnect stabil bleiben.

Stromprobleme lassen sich recht schwer analysieren. Die /dev/disk/by_id Methode greif in dem Fall nicht. Im Raid werden die Platten nach nicht mit /dev/sda angesprochen und gemountet werden die Platten ja nicht. Siehe mdadm.conf und fstab.

Code:
# mdadm.conf
DEVICE partitions
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>
MAILADDR root
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=5d705fbc:9ff297cf:852484a6:e390a598

Code:
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID=5d705fbc:9ff297cf:852484a6:e390a598 none auto nouser,noauto 0 0
proc            /proc           proc    defaults        0       0
/dev/hdc3       /               ext3    errors=remount-ro 0       1
/dev/hdc1       /boot           ext3    defaults        0       2
/dev/hdc4       /srv            ext3    defaults        0       2
/dev/hdc2       none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/md0        /mnt/usbraid    ext3    defaults        0       0

der UUID Eintrag ist die UUID der beiden Raidplatten. Der ist bei einer Raidplatte ja identisch mit der anderen.
 
OP
nbkr

nbkr

Guru
Kurzes Update. Es scheint jetzt zu funktionieren.

Um dem Problem Herr zu werden habe ich folgendes getan.

- Gehäuse der USB Festplatten getauscht. Vorher waren das Capitva Gehäuse - deren Controller schaltet die Platte bei Inaktivität ab.
- UUID in die fstab aufgenommen.
- Nach dem Tipp mit der Stromversorgung: Die Steckdose an denen die Platten hingen von Master/Slave (gehen aus wenn der zugehörige Rechner ausgeht) auf Normal umstellen.


Seit 5 Tagen läuft das Raid jetzt ohne Probleme.
 
Oben