Wir haben einen Dell PowerEdge T110 mit Fedora 14, der als unser Build-Server für Embedded Linux und als unser Subversion-Server fungiert.
In letzter Zeit ist es sehr langsam geworden und kann die nächtlichen Backups nicht mehr abschließen, bevor der neue Tag beginnt.
[EDIT] Danke User9517 - ich habe das Protokoll überprüft und es gibt mehrere Nachrichten von MRMON (Mega Raid Monitor). Alle Hinweise zur Interpretation dieser Nachrichten, zu den nächsten Schritten und zur Ermittlung, welches Laufwerk ausgetauscht werden muss, wären hilfreich.
Dec 20 09:02:32 localhost MR_MONITOR[2153]: <MRMON096> Controller ID: 0 PD Predictive failure: #012 -:-:2
Dec 20 09:06:44 localhost MR_MONITOR[2153]: <MRMON113> Controller ID: 0 Unexpected sense: PD #012 = -:-:2No defect spare location available, CDB = 0x28 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 , Sense = 0x70 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x32 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Dec 20 09:09:44 localhost MR_MONITOR[2153]: <MRMON096> Controller ID: 0 PD Predictive failure: #012 -:-:2
[/BEARBEITEN]
Ich brauche Hilfe bei der Fehlersuche. Ich bin definitiv kein Experte auf diesem Gebiet, die Person, die das System ursprünglich eingerichtet hat, ist nicht mehr hier.
Das nächtliche Backup umfasst eine TGZ-Datei von ungefähr 6 GByte und beginnt um 20 Uhr. Normalerweise war es gegen 4 Uhr morgens fertig (einschließlich Kopieren auf ein externes Laufwerk). Das wöchentliche Backup umfasst ungefähr 45 GByte und war normalerweise samstags um 11 Uhr fertig, nachdem es am Freitag um 20 Uhr begonnen hatte.
Zusätzlich zur Datensicherung reagiert die Maschine merklich langsam, selbst wenn der Sicherungsvorgang nicht läuft.
Folgendes habe ich bisher herausgefunden:
Es gibt einen RAID-Controller DELL PERC H200L mit vier angeschlossenen Seagate 1TB-Laufwerken (ST31000424SS). IchdenkenEs ist für RAID 10 eingerichtet, aber ich weiß nicht, wie ich auf die Konfiguration für diesen Controller zugreifen kann. Ich glaube, es ist RAID 10, da es 4 Laufwerke gibt und vgdisplay anzeigt, dass 1,81 Terabyte von den insgesamt 4 Terabyte auf den 4 Laufwerken zugewiesen sind.
[root@fedorabox backup]# vgdisplay
--- Volume group ---
VG Name vg_fedorabox2
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 8
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 5
Open LV 5
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.81 TiB
PE Size 32.00 MiB
Total PE 59263
Alloc PE / Size 28480 / 890.00 GiB
Free PE / Size 30783 / 961.97 GiB
Ich kann keine anderen tatsächlichen Laufwerke in der Maschine sehen, daher nehme ich an, dass die Bootpartition (/dev/sdb1) irgendwie aus den 4 Laufwerken heraus partitioniert ist.
(/dev/sda ist eine externe Festplatte für Backups - aber das ist nicht das Problem. Das Backup wird noch auf der /backup-Partition erstellt, als wir morgens ankommen. Das Kopieren auf das angeschlossene USB-Laufwerk wurde noch nicht gestartet.)
[root@fedorabox backup]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_fedorabox2-LogVol00
9.9G 5.2G 4.3G 55% /
tmpfs 2.0G 932K 2.0G 1% /dev/shm
/dev/sdb1 504M 56M 423M 12% /boot
/dev/mapper/vg_fedorabox2-LogVol03
394G 221G 153G 60% /home
/dev/mapper/vg_fedorabox2-LogVol02
99G 29G 65G 32% /shared
/dev/mapper/vg_fedorabox2-LogVol01
30G 11G 18G 37% /usr
/dev/sda2 5.5T 2.6T 3.0T 47% /mnt/root/usbbackup2
/dev/mapper/vg_fedorabox2-LogVol04
345G 363M 327G 1% /backup
wie ich in der Frage sagte, ist die Schreibgeschwindigkeitsehrlangsam:
[root@fedorabox backup]# dd if=/dev/zero of=/backup/tmp/test.out bs=512 count=32 oflag=dsync
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 40.382 s, 0.4 kB/s
[root@fedorabox backup]# dd of=/dev/null if=/backup/tmp/test.out bs=512 count=32 oflag=dsync
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 3.5087e-05 s, 467 MB/s
Ich kann mit smartctl auf die vier Laufwerke als /dev/sg2 bis /dev/sg5 zugreifen. Die Ausgabe ist unten aufgeführt. Ich weiß nicht, was das normale Lesen fürBehobene Fehlerhier, aber ich stelle fest, dass das zweite und vierte Laufwerk (/dev/sg3, sg5) aufgelistet sindnicht korrigierte Fehlerzum Auslesen und Prüfen.
Irgendwelche Ratschläge für die nächsten Schritte? Sind die nicht korrigierten Fehler normal oder besorgniserregend? Sind sie die Ursache für die Verlangsamung oder gibt es etwas anderes, das ich mir ansehen sollte?
Gibt es Ratschläge zum Ersetzen eines Laufwerks und zum Zugriff auf die RAID-Konfiguration?
[root@fedorabox /]# smartctl -a /dev/sg2
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST1000NM0001 Version: PS06
Serial number: Z1N2LEDW
Device type: disk
Transport protocol: SAS
Local Time is: Mon Dec 19 12:10:20 2022 EST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
Log Sense failed, IE page [scsi response fails sanity test]
Current Drive Temperature: 37 C
Drive Trip Temperature: 68 C
Manufactured in week 33 of year 2012
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 71
Elements in grown defect list: 36
Vendor (Seagate) cache information
Blocks sent to initiator = 2805494200
Blocks received from initiator = 1072424796
Blocks read from cache and sent to initiator = 19110177
Number of read and write commands whose size <= segment size = 826634038
Number of read and write commands whose size > segment size = 5264167
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 11183.37
number of minutes until next internal SMART test = 43
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 3996823525 0 0 3996823525 0 130.509 0
write: 0 0 0 0 0 62619.327 0
verify: 1594450892 0 0 1594450892 0 51866.259 0
Non-medium error count: 9
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 32 11182 - [- - -]
Long (extended) Self Test duration: 11100 seconds [185.0 minutes]
[root@fedorabox /]# smartctl -a /dev/sg3
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST31000424SS Version: KS68
Serial number: 9WK3JSJV
Device type: disk
Transport protocol: SAS
Local Time is: Mon Dec 19 12:10:44 2022 EST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
Log Sense failed, IE page [scsi response fails sanity test]
Current Drive Temperature: 37 C
Drive Trip Temperature: 68 C
Manufactured in week 06 of year 2011
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 81
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 81
Elements in grown defect list: 21
Vendor (Seagate) cache information
Blocks sent to initiator = 1872227385
Blocks received from initiator = 3603107317
Blocks read from cache and sent to initiator = 53905772
Number of read and write commands whose size <= segment size = 1041622488
Number of read and write commands whose size > segment size = 5288254
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 77337.02
number of minutes until next internal SMART test = 16
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 1454822558 3 0 1454822561 1454822585 2465.838 21
write: 0 0 0 0 0 64012.923 0
verify: 2113323340 143 0 2113323483 2113323510 49057.393 17
Non-medium error count: 4
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 643 - [- - -]
# 2 Background short Completed 16 5 - [- - -]
# 3 Background long Completed 16 5 - [- - -]
Long (extended) Self Test duration: 11100 seconds [185.0 minutes]
[root@fedorabox /]# smartctl -a /dev/sg4
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST31000424SS Version: KS68
Serial number: 9WK3H8DW
Device type: disk
Transport protocol: SAS
Local Time is: Mon Dec 19 12:11:02 2022 EST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
Log Sense failed, IE page [scsi response fails sanity test]
Current Drive Temperature: 38 C
Drive Trip Temperature: 68 C
Manufactured in week 06 of year 2011
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 76
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 76
Elements in grown defect list: 1
Vendor (Seagate) cache information
Blocks sent to initiator = 1437832391
Blocks received from initiator = 3080050213
Blocks read from cache and sent to initiator = 2689371046
Number of read and write commands whose size <= segment size = 3306395247
Number of read and write commands whose size > segment size = 5018225
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 77337.17
number of minutes until next internal SMART test = 58
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 1514637706 1007 0 1514638713 1514638713 1576907.538 0
write: 0 0 0 0 0 61240.330 0
verify: 1697580124 32 0 1697580156 1697580157 48889.638 0
Non-medium error count: 27
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 18 - [- - -]
# 2 Background short Completed 16 5 - [- - -]
# 3 Background long Completed 16 5 - [- - -]
Long (extended) Self Test duration: 11100 seconds [185.0 minutes]
[root@fedorabox /]# smartctl -a /dev/sg5
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST31000424SS Version: KS68
Serial number: 9WK3FCZ6
Device type: disk
Transport protocol: SAS
Local Time is: Mon Dec 19 12:11:41 2022 EST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
Log Sense failed, IE page [scsi response fails sanity test]
Current Drive Temperature: 38 C
Drive Trip Temperature: 68 C
Manufactured in week 06 of year 2011
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 81
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 81
Elements in grown defect list: 4096
Vendor (Seagate) cache information
Blocks sent to initiator = 923606853
Blocks received from initiator = 3074269061
Blocks read from cache and sent to initiator = 3237322768
Number of read and write commands whose size <= segment size = 3044372010
Number of read and write commands whose size > segment size = 5024782
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 77336.67
number of minutes until next internal SMART test = 53
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 2058067359 277563 0 2058344922 2058345511 1420772.201 555
write: 0 0 0 0 0 62186.800 0
verify: 2750944424 2205 0 2750946629 2750946631 50834.359 1
Non-medium error count: 167
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 643 - [- - -]
# 2 Background short Completed 16 5 - [- - -]
# 3 Background long Completed 16 5 - [- - -]
Long (extended) Self Test duration: 11100 seconds [185.0 minutes]
Antwort1
Dell PERC ist im Wesentlichen eine Umbenennung von LSI MegaRAID SAS.
Schauen Sie in Ihrem lspci -knach, welchen Treiber es verwendet. Wahrscheinlich ist es so megaraid_sas. Die Tatsache, dass Sie MegaRAID Monitor erfolgreich verwenden, lässt darauf schließen, dass dies der Fall sein muss. Mit dem megacliPaket wäre es also möglich, Ihren RAID-Controller von Linux aus zu steuern.
Wo man es heute für eine so alte Fedora-Version finden kann, bleibt jedoch eine Frage. Schauen Sie mal aufhttps://hwraid.le-vert.netfürMegaRAID SASoder möglicherweiseMegaRAIDfür die Software.
Die Software verfügt über eine kleine Inline-Erinnerung (run megacli -h) und auch beschrieben inDas MegaRAID SAS-Software-Benutzerhandbuchdie Sie erhalten beiBroadcom(Wer Avago gekauft hat, der LSI gekauft hat). Außerdem gibt es im Internet einige Spickzettel.
Sie können beispielsweise mit dem Abrufen von Diagnoseinformationen beginnen:
megacli -AdpAllInfo -aALL
megacli -AdpPR -info -aALL
megacli -LdPdInfo -aALL
megacli -AdpBbuCmd -GetBbuStatus -aALL
megacli -AdpEventLog -GetEventLogInfo -aALL
Diese Befehle bewirken jeweils Folgendes:
- Erhalten Sie den Status und allgemeine Warnungen des Controllers (einschließlich der Anzahl fehlerhafter Geräte)
- Erhalten Sie den Status von Patrol Read-Vorgängen (regelmäßiges Lesen aller Geräte, um fehlerhafte Geräte frühzeitig zu erkennen)
- Abrufen logischer Datenträger und deren physischer Datenträgerkomponentenmit ihrem StatusWenn es ausgefallene Festplatten gibt, wird Ihnen angezeigt, um welche Festplatten es sich handelt und in welchen Steckplätzen sie sich befinden.
- Den Cache-Batteriestatus abrufen
- Holen Sie sich die Ereignisprotokolle des Adapters. Diese können Ihnen dabei helfen, genau zu bestimmen, wann und unter welchen Umständen ein Problem erkannt wurde.
Die Tatsache, dass Sie über RAID verfügen, entbindet Sie nicht von der Pflicht, den Zustand Ihrer Festplatten und Ihres Arrays zu überwachen. RAID hilft nur bei ordnungsgemäßer Überwachung und Wartung, Ausfallzeiten zu vermeiden. smartmontoolskann Festplatten sogar hinter einigen Hardware-RAID-Controllern überwachen; nutzen Sie es!
Es ist an der Zeit, die Mantras „Berühre es nicht, wenn es funktioniert“ und „Repariere es nicht, wenn es nicht kaputt ist“ zu vergessen. Diese sind für die sich schnell entwickelnde Welt nicht relevant. Bedenken Sie Folgendes: Die alte Version von OSIstkaputt, weil es alt ist. Ein kompetenter AdministratorWilleReparieren Sie scheinbar „nicht kaputte“ Systeme, damit sie nicht kaputt gehen.
Was noch schlimmer ist: Ein altes (10 Jahre altes) Nicht-LTS-System wie Fedora ist völlig kaputt. Die Idee, irgendetwas von geschäftlicher Bedeutung auf einer solchen Distribution zu hosten, ist von Grund auf kaputt; wenn es CentOS wäre (was vor 10 Jahren LTS war, heute verwendet man stattdessen Oracle Linux, AlmaLinux oder Rocky Linux), wäre es nichtDasschlecht, aber Fedora war für einen Produktionsserver immer die falsche Wahl. Selbst wenn er erst zwei Jahre alt war, musste man ihn ersetzen.
Und installieren Sie am besten immer Hardware-Verwaltungstools ( megacliusw. ipmiutil). Sie wissen nie, wann Sie sie brauchen, und dann sind sie möglicherweise schon nicht mehr verfügbar, also verteilen Sie rechtzeitig etwas davon.