Raid anlegen bzw. umbauen

[Yvo]

Hi

Mein Ist-Zustand sieht so aus:
3 x 500 GB
1 x 1000 GB (das ist schon der Ersatz für eine kaputte Platte)
Zusammengefasst zu einem Raid 5 mit mehreren LVs drauf, u.a. um /home zu separieren; die übrigen 500 GB sind immer nur mal temporär im Einsatz

Das will ich nun daraus machen:
1 x 500 GB anderweitig nutzen
2 x 500 GB zu einem Raid 1 zusammenfassen und darauf das Betriebssystem (sowie ein paar weitere Dinge)
1 x 1000 GB + eine weitere (vorraussichtlich größere) Platte, die ich erst noch kaufen muss zu einem weiteren Raid 1 zusammenfassen, darauf soll /home
Kein LVM mehr, direkt Dateisystem mit ext3 auf beide Raids

Die Daten, die ich außer dem Betriebssystem aktuell habe, umfassen etwas mehr als 500 GB, daher kommt zum "Auslagern" während der Installation nur die 1TB Platte in Frage. Zum Vorgehen habe ich mir nun Folgendes überlegt:
- 1TB-Platte aus dem existierenden Raid 5 herausnehmen
- Auf dieser Platte ein Raid 1 anlegen und Daten drauf kopieren (geht das, wenn ich bei der Installation noch nicht beide Platten zur Verfügung habe?)
- Das Raid 5 ganz auflösen (das Betriebssystem brauch ich nicht mehr, zur Not gibt's auch noch ein Backup von dem ganzen)
- Auf zwei 500 GB Platten ein neues Raid 1 anlegen und Debian neu installieren
- Das andere Raid mit der 1000er Platte als /home mounten
- Sobald die neue Platte da ist, das /home-Raid um eine zweite Platte erweitern

Würdet ihr mit dieser Vorgehensweise irgendwelche Probleme erwarten oder sollte das klappen?
Insbesondere: Kann ich das Raid1 für /home auch schon anlegen, ohne die zweite Platte dazu zu haben? Das wäre sehr praktisch, weil ich dieses WE Zeit habe und so schnell keine Platte
Und ist es ein Problem, wenn die neue Platte Sata III ist und die vorhandenen alle SATA II? Oder nehme ich dann besser noch mal eine SATA II?
Habt ihr sonst irgendwelche Optimierungsvorschläge?

LG
Yvo

[Cae]

- Auf zwei 500 GB Platten ein neues Raid 1 anlegen und Debian neu installieren

Sofern du an diesem Punkt noch LVM haettest, koenntest du einfach das bestehende System schwenken. Haette u.a. den Vorteil, dass du globale Einstellungen nicht erneut machen musst.

Insbesondere: Kann ich das Raid1 für /home auch schon anlegen, ohne die zweite Platte dazu zu haben?

Ja, das ist explizit so vorgesehen:

Code: Alles auswählen

# mdadm --create md0 --level=raid1 --raid-devices=2 /dev/sda1 missing

Siehe auch CREATE MODE in der Manpage.

Und ist es ein Problem, wenn die neue Platte Sata III ist und die vorhandenen alle SATA II? Oder nehme ich dann besser noch mal eine SATA II?

Es koennte sein, dass die bestehende SATA2-Platte der Flaschenhals wird und die SATA3-Platte wegen des RAID1 unter ihrer moeglichen Leistung bleibt. Zukunfsfaehiger wird es aber sein, trotzdem SATA3 zu nehmen und irgendwann anstatt zwei SATA2-Platten nur eine upgraden zu muessen. Bei der ganzen Diskussion fragt sich auch, ob die Platten ueberhaupt die Datenraten erreichen koennen, die erst mit SATA3 moeglich werden.

Gruss Cae

[Dimejo]

Das will ich nun daraus machen:
1 x 500 GB anderweitig nutzen
2 x 500 GB zu einem Raid 1 zusammenfassen und darauf das Betriebssystem (sowie ein paar weitere Dinge)
1 x 1000 GB + eine weitere (vorraussichtlich größere) Platte, die ich erst noch kaufen muss zu einem weiteren Raid 1 zusammenfassen, darauf soll /home
Kein LVM mehr, direkt Dateisystem mit ext3 auf beide Raids

Warum ext3?

Die Daten, die ich außer dem Betriebssystem aktuell habe, umfassen etwas mehr als 500 GB, daher kommt zum "Auslagern" während der Installation nur die 1TB Platte in Frage. Zum Vorgehen habe ich mir nun Folgendes überlegt:
- 1TB-Platte aus dem existierenden Raid 5 herausnehmen
- Auf dieser Platte ein Raid 1 anlegen und Daten drauf kopieren (geht das, wenn ich bei der Installation noch nicht beide Platten zur Verfügung habe?)
- Das Raid 5 ganz auflösen (das Betriebssystem brauch ich nicht mehr, zur Not gibt's auch noch ein Backup von dem ganzen)
- Auf zwei 500 GB Platten ein neues Raid 1 anlegen und Debian neu installieren
- Das andere Raid mit der 1000er Platte als /home mounten
- Sobald die neue Platte da ist, das /home-Raid um eine zweite Platte erweitern

Würdet ihr mit dieser Vorgehensweise irgendwelche Probleme erwarten oder sollte das klappen?

Wenn Du so viele Daten von einem defekten Raid5 kopierst, dann solltest Du vorher auch sicherstellen, dass alles (Festplatten, Raid-Array und Filesystem) in Ordnung ist.

Und ist es ein Problem, wenn die neue Platte Sata III ist und die vorhandenen alle SATA II? Oder nehme ich dann besser noch mal eine SATA II?

Nein, kein Problem. Magnetfestplatten können weder SATA II noch SATA III ausreizen.

[Yvo]

Danke für eure Antworten!

Warum ext3?

Der Mensch ist ein Gewohnheitstier... empfiehlt sich für mein Setup etwas anderes mehr?

Wenn Du so viele Daten von einem defekten Raid5 kopierst, dann solltest Du vorher auch sicherstellen, dass alles (Festplatten, Raid-Array und Filesystem) in Ordnung ist.

Der SMART-Status sagt, dass eine meiner 500er-Platten fehlerhafte Sektoren hat Das sehe ich gerade zum ersten mal. Ich habe aus meinem bestehenden Raid noch nie manuell eine Platte herausgenommen, bis jetzt habe ich immer nur eine wieder eingefügt (irgendwie fliegt von Zeit zu Zeit immer mal wieder eine raus, aber immer eine andere und bis jetzt waren die SMART-Werte ok).
Vielleicht sollte ich doch besser warten, bis meine neue Festplatte da ist, wenn die eine mit den Fehlerhaften Sektoren nämlich genau dann stirbt, wenn ich die andere aus dem Raid rausnehme, habe ich ein Problem

LG
Yvo

[HumiNi]

Vielleicht sollte ich doch besser warten, bis meine neue Festplatte da ist, wenn die eine mit den Fehlerhaften Sektoren nämlich genau dann stirbt, wenn ich die andere aus dem Raid rausnehme, habe ich ein Problem

Ich will ja nicht oberlehrerhaft wirken, aber du weisst schon , dass ein RAID eher eine HA-Merkmal ist, aber keine Datensicherung ersetzt?

Entsorgter

[Yvo]

Ja, das weiß ich schon. Und mein Backup-System hat sich auch schon mehrfach als sehr gut erwiesen Trotzdem schrotte ich ungerne ein laufendes System und verlasse mich nur noch auf mein Backup. Doppelt hält eben besser. Wenn ich das Backup nicht brauche, freue ich mich mehr.

[NAB]

- Auf dieser Platte ein Raid 1 anlegen und Daten drauf kopieren (geht das, wenn ich bei der Installation noch nicht beide Platten zur Verfügung habe?)

Ja, das geht, und sieht dann ungefähr so aus:

Code: Alles auswählen

mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdX1

Das "missing" ist quasi ein Platzhalter für die fehlende Platte. Dass du dann keine Redundanz hast, muss ich wohl nicht erläutern.

Du könntest dasselbe auch mit der freien 500GB-Platte machen, dann das System umziehen, und dann erst das alte Raid5 auflösen.

Wenn das Radi5 nicht alle vier Platten braucht, kannst du auch versuchen, mit "mdadm --grow" eine Platte abzuzwacken ... das habe ich aber noch nie ausprobiert.

[r4pt0r]

Gerade bei unterschiedlichen Plattengrößen und öfter mal wachsenden Systemen wäre aber LVM ein enormer vorteil um sich später Konfigurationsaufwand zu sparen...
LVM kennt auch striped oder mirrored volumes - so kann man auch gezielt volumes spiegeln oder für mehr performance auf mehrere PVs verteilt schreiben.
Austausch/hinzufügen von Festplatten in beliebigen Größen ist "on-the-fly" im Betrieb möglich, ebenso wie Umziehen von Volumes auf andere Platten. mit lvm-snapshots wird auch noch das backup enorm vereinfacht und beschleunigt. Also ich wüsste nicht warum man in einem Fileserver darauf verzichten will/soll.


dateisystem: ext4, da es deutliche performancevorteile gegenüber ext3 bringt. online-größenänderungen sind damit auch problemlos möglich (bzw auch mit ext2+3)

[meti]

Ich würde dringend empfehlen LVM weiter zu nutzen.

Den ganzen Unterbau (das RAID und die Platten) kannst mit LVM sogar im laufenden Betrieb umbauen, sofern das ganze System auf dem LVM aufgesetzt ist. Nur ein abschließender Reboot empfiehlt sich, vor allem um Sicherzustellen das das Booten auch wirklich funktioniert. Ohne LVM, oder wenn nur die Datenpartitionen im LVM sind bist Du gezwungen mindestens 2x zu booten und Du musst zeitaufwändig und mit recht langer Unterbrechung das System im Prinzip neu aufsetzen. Kann man machen, muss man aber nicht.

Ich würde dein Setup mit HDD --> md --> LVM beibehalten. Und ggf. auf ext4 upgraden. Das geht auch im laufenden Betrieb.

Es ist zwar mittlerweile wohl möglich mit LVM alleine ein RAID aufzubauen, aber ich würd das nicht empfehlen. Das ist noch nicht wirklich erprobt und wäre mir zu unsicher für produktiven Betrieb. Nur ein RAID mit mdadm ist viel zu unflexibel und ganz ehrlich, LVM ist durchaus machbar wenn man sich a bisserl damit beschäftigt.

[r4pt0r]

Ich nutze seit ~1 Jahr ein striped Volume in einem Produktivserver. Darunter liegen 2x raid1 (md) - die Performance des volumes (für eine VM) ist identisch bzw teilweise sogar etwas flotter als das zuvor eingesetzte raid-10 an einem LSI megaraid.
mirrored LVs setze ich (noch) keine ein - allerdings nur weil ich bisher immer je 2 identische platten einsetze die dann direkt als raid1 per md laufen. darüber kommt dann ein PV.

Zum Upgrade auf ext4: für weniger "kritische" partitionen bei denen man durch ext4 nicht viel gewinnt, reicht es das ext3-dateisystem als ext4 einzubinden. Dadurch wird der ext4 Kerneltreiber genutzt der den Großteil des Geschwindigkeitsvorteils ausmacht.

Das IMHO sinnvollste wäre, eine der 500GB Platten gegen eine weitere 1TB zu ersetzen, je ein 1TB und 500GB raid1 erstellen und darauf jeweils ein LVM-PV. Booten von LVs funktioniert mittlerweile absolut zuverlässig, daher halte ich eine /boot Partition direkt im raid mittlerweile für überflüssig - die höhere Flexibilität eines LVs überwiegt hier deutlich.

Die Migration könnte folgendermaßen aussehen:

- alle LVs per pvmove auf die 1TB Platte verschieben (mittels "pvs -o+pv_used" sieht man wo welches LV physisch abgelegt wurde)
- alle 3 500GB Platten mittels vgreduce/pvremove aus dem LVM nehmen
- auf 2 der 500GB Platten ein raid1 erstellen + pvcreate + vgextend
- LVs auf das PV im raid verschieben
- raid 1 aus den beiden 1TB platten (oder ein 500GB mirror aus 1tb+500GB und später erweitern) + pvcreate + vgextend
- LVs nach bedarf erweitern und ggf striped über beide raid1 verteilen.


Wichtig für ein reibungslosen nächsten bootvorgang:
PVs IMMER mit vgreduce + pvremove entfernen! sonst bleiben verwaiste Einträge in der LVM-konfiguration zurück!
Nachdem alles neu angelegt ist ein "mdadm --examine --scan > /etc/mdadm/mdadm.conf && update-initramfs -u -k all" ausführen sowie grub in die entsprechenden MBRs schreiben. Das system muss zwar nicht neu gestartet werden, wenn die Downtime nicht stört macht es aber sinn das gleich auszutesten bevor man die Hälfte vergessen aht die man gerade Konfiguriert hat...

[Yvo]

Danke erst mal für alle zwischenzeitlich hinzugekommenen Tipps!

Meine Festplattenbestellung ist eingetroffen und eingebaut
Es gibt nun zwei neue 2TB Platten, die ich gerne als ein Raid 1 für /home und ein paar andere Dinge nutzen würde. Auf diese will ich nun zuerst mal Daten schieben und dann auf den alten 500er Platten (auch ein Raid 1) das Betriebssystem neu aufsetzen.

Auf Downtimes oder ähnliches kommt es übrigens auch nicht an, mein Rechner läuft eh nicht rund um die Uhr
Es mag etwas außergewöhnlich sein, sowas zu Hause aufzusetzen, aber dafür hab ich mich definitiv entschieden, war ja vorher auch schon nicht trivialer aufgesetzt und wenn alles läuft, ist es super bequem.

Aaaalso: Ihr habt mich davon überzeugt, doch wieder LVM zu verwenden und jetzt auch endlich mal auf ext4 umzusteigen. Meine zwei neuen Platten sind eingebaut, haben den ausführlichen SMART Selbsttest bestanden, es gibt eine neue Volume Group und ich habe ein erstes LV für mein zukünftiges /home angelegt. Letzteres habe ich nun mit

mkfs.ext4 /dev/glueckskaefer/home

formatiert und nun stehe ich vor einem Problem: Ich habe einen Blick in die Gnome-Laufwerksverwaltung geworfen und die präsentiert für meine beiden neuen 2TB Platten nun diese Meldung:

"Warning: The partition is misaligned by 3584 bytes. This may result in very poor performance. Repartitioning is suggested."

Ich kann mit den beiden Platten gerne noch mal von vorne anfangen, nur was muss ich jetzt anders machen?

[Cae]

Angenommen, diese Angabe stimmt: Sie bedeutet, dass du auf der physikalischen Platte eine Anzahl Blocke hast, aber die virtuellen Bloecke der durch den MBR definierte Partition um 3584 Bytes daneben liegt. Dies kann dazu fuehren, dass beim Beschreiben oder lesen von genau einem virtuellen Block ploetzlich zwei physikalische Bloecke angefasst werden muessen, was offensichtlich nicht optimal ist.

In deinem Fall geht die erste bzw. betroffene Partition direkt nach dem MBR los (512 Bytes) und du hast eine Bockgroesse von 4k, zumindest kommt das bei der Rechnung

Code: Alles auswählen

$ bc -ql
4096 - 3584
512
$ 

raus. Die Loesung dazu besteht darin, die Partition(en) wieder abzureissen und neu anzulegen. Allerdings diesmal mit einem Offset von n*4096 Bytes, z.B. der Einfachheit halber bei 1MB. fdisk fragt explizit nach so einem Offset, z.B. als

Code: Alles auswählen

First sector (2048-409599, default 2048):

und macht in neueren Versionen imho auch direkt den Offset richtig. Wobei meine Version offensichtlich nicht dazu gehoert, denn

Code: Alles auswählen

$ stat -c %o image 
4096

ist eigentlich die erkannte und imho auch korrekte "physikalische" Blockgroesse (das ist eine per truncate -s 200M image angelegte Datei im Dateisystem).

Gruss Cae

[Yvo]

Mit fdisk hat's funktioniert

Jetzt habe ich leider das nächste Problem:

LVGruppe angelegt, LV angelegt, soweit hat's noch geklappt.

Dann
mkfs.ext4 /dev/lvgruppe/meinlv

Seitdem ist das Raid herabgestuft:
md127 : active raid1 sdc1[1] sda1[0](F)
1953512400 blocks super 1.2 [2/1] [_U]

[Yvo]

Hat dazu zufällig jemand eine Idee?

LG
Yvo

[Cae]

Wird da das korrekte PV verwendet (pvs, vgs)? Steht dazu im dmesg bzw. Syslog etwas, warum das RAID auseinander gefallen ist? Ist die "was liegt in was drin"-Visualisierung von lsblk plausibel?

Gruss Cae

[Yvo]

Hi

Habe das ganze gerade noch mal wiederholt, diesmal etwas mehr Zeit zwischen den Befehlen gelassen und im Syslog verfolgt, was da so steht.

Das Raid fängt nach vgcreate an, die beiden Platten zu synchronisieren, aber scheitert daran, es fliegt also schon vor dem Anlegen des Dateisystems auseinander:

cat /proc/mdstat :

Code: Alles auswählen

Personalities : [raid1] [raid6] [raid5] [raid4] 
md127 : active raid1 sdc1[1] sda1[0]
      1953512400 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  1.3% (27130752/1953512400) finish=710.1min speed=45207K/sec
      
md2 : active raid1 sdb1[0] sdd1[3] sde1[2] sdf1[1]
      248896 blocks [4/4] [UUUU]
      
md1 : active raid5 sdb2[0] sde2[4] sdd2[2] sdf2[5]
      1464403968 blocks super 1.1 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
unused devices: <none>

cat /proc/mdstat einen kleinen Moment später:

Code: Alles auswählen

Personalities : [raid1] [raid6] [raid5] [raid4] 
md127 : active raid1 sdc1[1] sda1[0](F)
      1953512400 blocks super 1.2 [2/1] [_U]
      
md2 : active raid1 sdb1[0] sdd1[3] sde1[2] sdf1[1]
      248896 blocks [4/4] [UUUU]
      
md1 : active raid5 sdb2[0] sde2[4] sdd2[2] sdf2[5]
      1464403968 blocks super 1.1 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      
unused devices: <none>

Zu
mdadm --create /dev/md/glueckskaefer --level=1 --raid-devices=2 /dev/sda1 /dev/sdc1
sagt das syslog:

Code: Alles auswählen

Nov  9 12:02:40 sonnenblume mdadm[2239]: NewArray event detected on md device /dev/md127
Nov  9 12:02:40 sonnenblume kernel: [ 3895.504995] md: bind<sda1>
Nov  9 12:02:40 sonnenblume kernel: [ 3895.505902] md: bind<sdc1>
Nov  9 12:02:40 sonnenblume kernel: [ 3895.507940] raid1: md127 is not clean -- starting background reconstruction
Nov  9 12:02:40 sonnenblume kernel: [ 3895.507947] raid1: raid set md127 active with 2 out of 2 mirrors
Nov  9 12:02:40 sonnenblume kernel: [ 3895.507988] md127: detected capacity change from 0 to 2000396697600
Nov  9 12:02:40 sonnenblume kernel: [ 3895.508383]  md127:

Zu
vgcreate glueckskaefer /dev/md/glueckskaefer
sagt das syslog (ewige Wiederholungen ausgelassen):

Code: Alles auswählen

Nov  9 12:37:58 sonnenblume kernel: [ 6010.057889] md: resync of RAID array md127
Nov  9 12:37:58 sonnenblume kernel: [ 6010.057893] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Nov  9 12:37:58 sonnenblume kernel: [ 6010.057895] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
Nov  9 12:37:58 sonnenblume kernel: [ 6010.057900] md: using 128k window, over a total of 1953512400 blocks.
Nov  9 12:37:58 sonnenblume mdadm[2239]: RebuildStarted event detected on md device /dev/md127
Nov  9 12:39:01 sonnenblume /USR/SBIN/CRON[5002]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093379] ata4.00: exception Emask 0x0 SAct 0xffff SErr 0x0 action 0x6 frozen
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093387] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093396] ata4.00: cmd 60/80:00:00:35:b6/00:00:02:00:00/40 tag 0 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093398]          res 40/00:08:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093402] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093406] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093415] ata4.00: cmd 60/80:08:80:35:b6/00:00:02:00:00/40 tag 1 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093417]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093421] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093425] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093433] ata4.00: cmd 60/80:10:00:36:b6/00:00:02:00:00/40 tag 2 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093435]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093439] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093443] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093451] ata4.00: cmd 60/80:18:80:36:b6/00:00:02:00:00/40 tag 3 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093453]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093458] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093461] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093470] ata4.00: cmd 60/80:20:00:37:b6/00:00:02:00:00/40 tag 4 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093472]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093476] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093480] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093488] ata4.00: cmd 60/80:28:80:33:b6/00:00:02:00:00/40 tag 5 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093490]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093494] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093498] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093506] ata4.00: cmd 60/80:30:00:34:b6/00:00:02:00:00/40 tag 6 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093508]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093512] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093516] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093524] ata4.00: cmd 60/80:38:80:34:b6/00:00:02:00:00/40 tag 7 ncq 65536 in
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093526]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093531] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093534] ata4.00: failed command: READ FPDMA QUEUED

[...]



Nov  9 12:40:58 sonnenblume kernel: [ 6190.093677] ata4.00: status: { DRDY }
Nov  9 12:40:58 sonnenblume kernel: [ 6190.093684] ata4: hard resetting link
Nov  9 12:40:58 sonnenblume kernel: [ 6190.577464] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 370)
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580832] ata4.00: configured for UDMA/133
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580840] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580844] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580848] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580851] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580855] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580859] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580862] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580866] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580869] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580873] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580877] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580880] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580884] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580887] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580891] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580895] ata4.00: device reported invalid CHS sector 0
Nov  9 12:40:58 sonnenblume kernel: [ 6190.580917] ata4: EH complete
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971582] ata4.00: exception Emask 0x0 SAct 0xffff SErr 0x0 action 0x6 frozen
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971590] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971599] ata4.00: cmd 60/80:00:00:fe:d2/00:00:02:00:00/40 tag 0 ncq 65536 in
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971601]          res 40/00:08:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971606] ata4.00: status: { DRDY }
Nov  9 12:41:35 sonnenblume kernel: [ 6226.971610] ata4.00: failed command: READ FPDMA QUEUED


[...]


Nov  9 12:42:29 sonnenblume kernel: [ 6280.898736]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898740] ata4.00: status: { DRDY }
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898744] ata4.00: failed command: READ FPDMA QUEUED
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898752] ata4.00: cmd 60/80:78:80:0e:3c/00:00:03:00:00/40 tag 15 ncq 65536 in
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898754]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898758] ata4.00: status: { DRDY }
Nov  9 12:42:29 sonnenblume kernel: [ 6280.898766] ata4: hard resetting link
Nov  9 12:42:29 sonnenblume kernel: [ 6281.381814] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 370)
Nov  9 12:42:34 sonnenblume kernel: [ 6286.375008] ata4.00: qc timeout (cmd 0xec)
Nov  9 12:42:34 sonnenblume kernel: [ 6286.375021] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Nov  9 12:42:34 sonnenblume kernel: [ 6286.375026] ata4.00: revalidation failed (errno=-5)
Nov  9 12:42:34 sonnenblume kernel: [ 6286.375031] ata4: hard resetting link
Nov  9 12:42:35 sonnenblume kernel: [ 6286.858259] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 370)
Nov  9 12:42:45 sonnenblume kernel: [ 6296.844633] ata4.00: qc timeout (cmd 0xec)
Nov  9 12:42:45 sonnenblume kernel: [ 6296.844646] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Nov  9 12:42:45 sonnenblume kernel: [ 6296.844651] ata4.00: revalidation failed (errno=-5)
Nov  9 12:42:45 sonnenblume kernel: [ 6296.844656] ata4: limiting SATA link speed to 3.0 Gbps
Nov  9 12:42:45 sonnenblume kernel: [ 6296.844662] ata4: hard resetting link
Nov  9 12:42:45 sonnenblume kernel: [ 6297.328009] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287273] ata4.00: qc timeout (cmd 0xec)
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287286] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287291] ata4.00: revalidation failed (errno=-5)
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287295] ata4.00: disabled
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287304] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287308] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287312] ata4.00: device reported invalid CHS sector 0


[...]


Nov  9 12:43:15 sonnenblume kernel: [ 6327.287349] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287353] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287357] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287360] ata4.00: device reported invalid CHS sector 0
Nov  9 12:43:15 sonnenblume kernel: [ 6327.287371] ata4: hard resetting link
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771008] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771044] ata4: EH complete
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771072] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771075] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771080] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0e 80 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771092] end_request: I/O error, dev sda, sector 54267520
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771155] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771159] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771165] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0e 00 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771178] end_request: I/O error, dev sda, sector 54267392
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771189] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771192] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771197] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0d 80 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771207] end_request: I/O error, dev sda, sector 54267264
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771214] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771217] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771222] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0d 00 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771232] end_request: I/O error, dev sda, sector 54267136
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771239] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771242] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771246] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0c 80 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771256] end_request: I/O error, dev sda, sector 54267008
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771264] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771267] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771272] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 0c 00 00 00 80 00
Nov  9 12:43:16 sonnenblume kernel: [ 6327.771282] end_request: I/O error, dev sda, sector 54266880



[...]



Nov  9 12:43:16 sonnenblume kernel: [ 6328.129543] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129546] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129549] sd 2:0:0:0: [sda] CDB: Write(10): 2a 00 03 3c 16 78 00 00 08 00
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129558] end_request: I/O error, dev sda, sector 54269560
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129578] sd 2:0:0:0: [sda] Unhandled error code
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129580] sd 2:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129584] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 03 3c 16 78 00 00 08 00
Nov  9 12:43:16 sonnenblume kernel: [ 6328.129593] end_request: I/O error, dev sda, sector 54269560
Nov  9 12:43:16 sonnenblume kernel: [ 6328.141974] md: checkpointing resync of md127.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.168819] RAID1 conf printout:
Nov  9 12:43:16 sonnenblume kernel: [ 6328.168824]  --- wd:1 rd:2
Nov  9 12:43:16 sonnenblume kernel: [ 6328.168828]  disk 0, wo:1, o:0, dev:sda1
Nov  9 12:43:16 sonnenblume kernel: [ 6328.168832]  disk 1, wo:0, o:1, dev:sdc1
Nov  9 12:43:16 sonnenblume mdadm[2239]: Rebuild99 event detected on md device /dev/md127
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205918] RAID1 conf printout:
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205923]  --- wd:1 rd:2
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205927]  disk 1, wo:0, o:1, dev:sdc1
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205977] md: resync of RAID array md127
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205980] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205983] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205990] md: using 128k window, over a total of 1953512400 blocks.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205993] md: resuming resync of md127 from checkpoint.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.205996] md: md127: resync done.
Nov  9 12:43:16 sonnenblume kernel: [ 6328.210343] RAID1 conf printout:
Nov  9 12:43:16 sonnenblume kernel: [ 6328.210348]  --- wd:1 rd:2
Nov  9 12:43:16 sonnenblume kernel: [ 6328.210352]  disk 1, wo:0, o:1, dev:sdc1
Nov  9 12:43:16 sonnenblume mdadm[2239]: RebuildFinished event detected on md device /dev/md127

Und nun ist das Raid wieder herabgestuft

Könnt ihr das Syslog besser interpretieren als ich und mir wieder mal einen guten Tipp geben?

Liebe Grüße
Yvo

[Dimejo]

Hast Du die Festplatte überprüft?

Code: Alles auswählen

smartctl --test=short /dev/sda

Nach dem Ablauf der angegebenen Zeit:

Code: Alles auswählen

smartctl --attributes --log=selftest /dev/sda

[Yvo]

Außer, dass ich erst mal den Rechner neu starten musste, bevor ich den Selbsttest starten konnte, scheint das gut auszusehen:

Code: Alles auswählen

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   135   135   054    Pre-fail  Offline      -       85
  3 Spin_Up_Time            0x0007   141   141   024    Pre-fail  Always       -       494 (Average 388)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       12
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   119   119   020    Pre-fail  Offline      -       35
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       55
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       12
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       13
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       13
194 Temperature_Celsius     0x0002   166   166   000    Old_age   Always       -       36 (Lifetime Min/Max 19/40)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%        55         -
# 2  Short offline       Completed without error       00%        55         -
# 3  Extended offline    Completed without error       00%         5         -

Bevor ich mit den Festplatten angefangen habe (sind für den Zweck neu gekauft), habe ich auch auf beiden den ausführlichen Selbsttest über die Gnome Laufwerksverwaltung laufen lassen und da war auch alles ok mit den SMART-Werten.

LG
Yvo

[Yvo]

Ich hab's!!!

Es hat ein (erneutes) pvcreate gefehlt, nachdem ich zum x. mal von vorne angefangen habe... danach ging auch der Rest ohne, dass das Raid auseinandergeflogen ist.

Gibt es irgendwas, was ich noch mal prüfen sollte, bevor ich die Platten mit Daten fülle?

LG
Yvo

[Cae]

Es hat ein (erneutes) pvcreate gefehlt, nachdem ich zum x. mal von vorne angefangen habe... danach ging auch der Rest ohne, dass das Raid auseinandergeflogen ist.

Dann ist die Sache relativ klar: Dein LVM hat die ganze Zeit schon "am RAID vorbei" auf der Platte gelegen, und bei jedem vgcreate wurden dann Teile des RAID(-Metadatenteils?) ueberschrieben, weshalb mdadm die Platte rausgekickt hatte.

Gibt es irgendwas, was ich noch mal prüfen sollte, bevor ich die Platten mit Daten fülle?

Man koennte nochmal mit badblocks oder dd/aespipe/sha1sum Daten draufschreiben und beim Lesen kontrollieren, aber theoretisch ist das ueberfluessig, wenn die Hardware intakt ist. Wobei diese "ata command failed"-Meldungen eigentlich eher nicht darauf hinweisen.

Gruss Cae

[Yvo]

Ich glaube, ich weiß jetzt, was für ein Problem die Platten ab und zu haben. Eigentlich sind es nicht die Platten:
Es fliegt immer mal wieder eine aus dem Raid, nicht immer die gleiche. Rechner runterfahren, am Kabel wackeln, Rechner wieder hoch fahren, Platte geht wieder

Frage mich, ob ich besonders schlechte Kabel erwischt habe...

LG
Yvo

[Cae]

Oh ja, die Kabel. Schmeiss' die alle raus und kauf' dir gescheite neue Kabel mit einrastenden Sicherungsbuegeln. Zumindest war das fuer mich immer die Loesung und mit 20-25 EUR ist das noch ueberschaubar zum "nur ausprobieren".

Gruss Cae