Unregelmäßige "GEOM_ELI: Crypto request failed (ENOMEM)" Meldungen

[gadean]

Hey,
ich könnte mal wieder eure Hilfe gebrauchen, nach dem ich dazu leider nichts brauchbares im Netz finden konnte.

Ich hab eine Kiste mit 14.1-RELEASE welche aktuell unregelmäßig folgende Logs produziert:

Spoiler

Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada1p1.eli[WRITE(offset=15233591767040, length=1028096)]
Jul 29 04:11:49 storage syslogd: last message repeated 3 times
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743460089856, length=1032192)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233591767040, length=1028096)]
Jul 29 04:11:49 storage syslogd: last message repeated 1 times
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada1p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage syslogd: last message repeated 11 times
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743462334464, length=995328)]
Jul 29 04:11:49 storage syslogd: last message repeated 1 times
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage syslogd: last message repeated 12 times
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada1p1.eli[WRITE(offsGEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233595748352, length=1032192)]
Jul 29 04:11:49 storage kernel: et=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offsGEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: et=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada3p1.eli[WRITE(offset=15233593749504, length=987136)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada2p1.eli[WRITE(offset=15743463329792, length=1048576)]
Jul 29 04:11:49 storage kernel: GEOM_ELI: Crypto request failed (ENOMEM). ada0p1.eli[WRITE(offset=15743463104512, length=1011712)]

Kurz zum Setup:
Die Kiste hat 4x HDD, darauf GELI und dann ZFS
Für die Netzfreigabe wird net/samba416 benutzt.

# zpool status
  pool: zdata
 state: ONLINE
  scan: scrub repaired 0B in 21:53:21 with 0 errors on Wed Jul 24 01:49:16 2024
config:

        NAME            STATE     READ WRITE CKSUM
        zdata           ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            ada3p1.eli  ONLINE       0     0     0
            ada1p1.eli  ONLINE       0     0     0
          mirror-1      ONLINE       0     0     0
            ada2p1.eli  ONLINE       0     0     0
            ada0p1.eli  ONLINE       0     0     0

errors: No known data errors

# zfs get all zdata/backup | grep comp
zdata/backup  compressratio         1.39x                  -
zdata/backup  compression           lz4                    local
zdata/backup  refcompressratio      1.56x                  -

Jetzt habe ich zum zweiten mal (22. & 29.07.), eine Reihe von den Logs in /var/log/messages vorgefunden und mir ist nicht ganz klar, was das bedeuten soll.
Jedes mal lief zu dem Zeitpunkt ein wöchentliches Backup, das ca. 600GB Daten von einem anderen Server (Proxmox-VE) via smb auf diese Kiste schreibt.

Meine Vermutung ist, das es irgendwie mit dem Schreibprozess des Backups (und/oder compression) zusammenhängt, da zu anderen Zeitpunkten teilst weit mehr Daten via smb auf die Kiste geschrieben werden und auch lokal erzeugt werden, ohne das die Meldungen auftauchen. Scrub läuft auch ohne Probleme durch.

S.M.A.R.T. Werte sehen unauffällig aus und die Steckverbindungen habe ich ebenfalls nochmal geprüft (die würde eher andere Fehler produzieren).

 

[mr44er]

ENOMEM (Error NOt enough MEMory) geht eher in Richtung "System ging beim Schreiben die Luft aus (zu wenig swap/RAM)" aus geli-Sicht.

Bitte poste sicherheitshalber trotzdem mal von allen Platten die Infos smartctl -x -q noserial /dev/daX

 

[Andy_m4]

ENOMEM weist eher auf Out-of-Memory hin. Wobei ich mir gar nicht sicher bin, ob hier der normale RAM gemeint ist.
Der Fehler tritt auf, wenn g_eli_alloc_data fehlschlägt.

 

[gadean]

Gerne doch, anbei die SMART-Werte der vier Platten.

Die Kiste hat 64GB RAM, dort läuft nur smb und syncthing.

Hier auch ein Ausschnitt von top:

Mem: 23M Active, 8409M Inact, 18M Laundry, 33G Wired, 104K Buf, 20G Free
ARC: 6914M Total, 6330M MFU, 406M MRU, 31M Header, 146M Other
     6608M Compressed, 12G Uncompressed, 1.93:1 Ratio
Swap: 2048M Total, 161M Used, 1887M Free, 7% Inuse

Interessant ist, das Swap 161M Used ausspuckt, dafür das auf der Kiste nichts weiter läuft

# sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 0

Edit: Ich Idiot hätte ja auch mal nur nach "freebsd enomem" suchen können (anstatt im Kontext von geli/zfs):

       12  ENOMEM Cannot allocate memory.  The new process image required more
	       memory than was allowed by the hardware	or  by	system-imposed
	       memory  management  constraints.	  A lack of swap space is nor-
	       mally temporary;	however, a lack	of core	is not.	  Soft	limits
	       may be increased	to their corresponding hard limits.

Aber erklären kann ich mir das trotzdem nicht.
Wild geraten, vielleicht mal vfs.zfs.arc_max auf 32GB setzen, damit mehr für andere Dinge übrig bleibt?

 

[mr44er]

Interessant ist, das Swap 161M Used ausspuckt, dafür das auf der Kiste nichts weiter läuft

Ja, jetzt im Moment. Wie das aussieht während der die 600GB wegschluckt, ist nochmal was anderes.

Wild geraten, vielleicht mal vfs.zfs.arc_max auf 32GB setzen, damit mehr für andere Dinge übrig bleibt?

Seitens ZFS ist eigentlich soviel optimiert worden, dass man das nur noch in Ausnahmefällen antatschen muss und der ARC nicht mehr zäh in der Freigabe ist. Dennoch ist das einen Versuch wert.
Etwas mehr vermute ich aber, dass sich Samba währenddessen so aufbläht. Quasi so https://www.truenas.com/community/threads/samba-using-up-most-of-the-ram.61039/post-441048
Aus dem Ärmel geschüttelt fiele mir jetzt auch zu Samba nichts ein, was ein Killerparameter für "schreib schneller aus, du musst mit 128MB RAM klarkommen" wäre. Du müsstest mal das Backup anstupsen und schauen, welcher Prozess durch die Decke geht.

Und dann haben wir noch die Platten. Der Zustand ist bei allen perfekt, jedoch fielen mit zwei Dinge auf.
Alle haben sie schon Resets und ASR events (Asynchronous Signal Recovery):

0x06  0x008  4             197  ---  Number of Hardware Resets
0x06  0x010  4             138  ---  Number of ASR Events

Es ist nicht ungewöhnlich, wenn sowas mal passiert und dann kann man das eher vernachlässigen. Diese Platten weisen es aber alle auf und so frisch wie die sind (keine 10000h Laufzeit) ist es dann doch wieder ungewöhnlich. Da hätten wir zur Auswahl: Labberige Verbindung an den Steckern (an der Platte als auch Board) sowie Strom. Abhilfe schaffen SATA-Kabel mit Metallbügeln. Dein Netzteil ist vielleicht alt und degradiert, hat Schwankungen.

Punkt2:

APM level is:     128 (minimum power consumption without standby)

128 ist eher eine Einstellung für den Desktop, das beinhaltet oft langsamer drehen, Kopf parken oder eine Mischung aus allem, müsste man im Handbuch für Details mal schauen.
Jedenfalls könnte das auch stören und Folgefehler triggern. hdparm -B 255 /dev/daXoder wenn das nicht geht, hdparm -B 254 /dev/daX und damit erneut testen.
Sollte es das sein, dann müssen wir schauen, wie man den Platten das APM permanent beibringt. Aber erst eins nach dem anderen.

 

[Yamagi]

Speicherfragmentation könnte da auch mit reinspielen. Viele Kernel-Subsysteme arbeiten auf physischen Adressen und nicht auf virtuellen Adressen. Dazu gehört auch GEOM. Wenn es kein zusammenhängendes Segment mehr in der Länge, die geli sich allokieren möchte, gibt, schlägt die Allokation fehl und es gibt einen Fehler. Allerdings sollte Speicherfragmentation auch nur bei sehr wenig freiem Speicher ein Problem sein.

 

[gadean]

Das mit dem ARC hatte ich auch so im Hinterkopf, weswegen ich das nicht mehr setzte.

Die Resets/ASR Events hatte ich übersehen und ist merkwürdig, die Kabel (Power & Data) sind solche mit Bügel.

Ich habe das jetzt noch mit APM level: 128 getestet und es sind wieder die Fehler aufgetreten, währenddessen ist Swap auf 18% hochgegangen, ansonsten nur gelegentlich paar Kilobyte "in". Werde das später nochmal mit einem höheren Wert testen.

Der smbd Prozess hatte zu dem Zeitpunkt 17G bzw. 12G reserviert.
Anbei ein paar Screenshots, die ich mehr oder weniger direkt zum Zeitpunkt der Fehler gemacht habe.

Und ein Auszug aus dem Log des Backup-Prozesses:

Spoiler

870: 2024-07-29 14:58:25 INFO:  28% (56.1 GiB of 200.0 GiB) in 1m 9s, read: 897.8 MiB/s, write: 668.0 MiB/s
870: 2024-07-29 14:58:29 INFO:  29% (58.6 GiB of 200.0 GiB) in 1m 13s, read: 649.8 MiB/s, write: 459.2 MiB/s
870: 2024-07-29 14:58:35 INFO:  30% (61.3 GiB of 200.0 GiB) in 1m 19s, read: 454.3 MiB/s, write: 335.2 MiB/s
870: 2024-07-29 14:58:38 INFO:  31% (62.1 GiB of 200.0 GiB) in 1m 22s, read: 292.4 MiB/s, write: 254.8 MiB/s
870: 2024-07-29 14:58:43 INFO:  32% (64.9 GiB of 200.0 GiB) in 1m 27s, read: 564.8 MiB/s, write: 441.5 MiB/s
870: 2024-07-29 14:58:46 INFO:  33% (67.1 GiB of 200.0 GiB) in 1m 30s, read: 771.2 MiB/s, write: 555.0 MiB/s
870: 2024-07-29 14:58:50 INFO:  34% (69.3 GiB of 200.0 GiB) in 1m 34s, read: 562.6 MiB/s, write: 426.4 MiB/s
870: 2024-07-29 14:58:53 INFO:  35% (71.3 GiB of 200.0 GiB) in 1m 37s, read: 652.5 MiB/s, write: 485.2 MiB/s
870: 2024-07-29 14:58:56 INFO:  36% (73.6 GiB of 200.0 GiB) in 1m 40s, read: 791.5 MiB/s, write: 480.2 MiB/s
870: 2024-07-29 14:59:03 INFO:  37% (75.6 GiB of 200.0 GiB) in 1m 47s, read: 289.5 MiB/s, write: 176.9 MiB/s
870: 2024-07-29 14:59:06 INFO:  39% (78.1 GiB of 200.0 GiB) in 1m 50s, read: 879.8 MiB/s, write: 471.6 MiB/s
870: 2024-07-29 14:59:10 INFO:  40% (80.6 GiB of 200.0 GiB) in 1m 54s, read: 637.9 MiB/s, write: 421.0 MiB/s
870: 2024-07-29 14:59:14 INFO:  41% (83.9 GiB of 200.0 GiB) in 1m 58s, read: 840.1 MiB/s, write: 518.9 MiB/s
870: 2024-07-29 14:59:17 INFO:  42% (85.8 GiB of 200.0 GiB) in 2m 1s, read: 634.4 MiB/s, write: 419.8 MiB/s
870: 2024-07-29 14:59:20 INFO:  43% (87.2 GiB of 200.0 GiB) in 2m 4s, read: 485.8 MiB/s, write: 288.3 MiB/s
870: 2024-07-29 15:00:06 INFO:  44% (88.7 GiB of 200.0 GiB) in 2m 50s, read: 33.7 MiB/s, write: 14.9 MiB/s
870: 2024-07-29 15:00:09 INFO:  45% (90.9 GiB of 200.0 GiB) in 2m 53s, read: 747.3 MiB/s, write: 370.1 MiB/s
870: 2024-07-29 15:00:17 INFO:  46% (92.2 GiB of 200.0 GiB) in 3m 1s, read: 173.1 MiB/s, write: 123.3 MiB/s
870: 2024-07-29 15:00:20 INFO:  47% (95.6 GiB of 200.0 GiB) in 3m 4s, read: 1.1 GiB/s, write: 550.6 MiB/s
870: 2024-07-29 15:00:23 INFO:  49% (99.5 GiB of 200.0 GiB) in 3m 7s, read: 1.3 GiB/s, write: 326.3 MiB/s

// ...

951: 2024-07-29 15:03:26 INFO:  48% (48.4 GiB of 100.0 GiB) in 54s, read: 661.6 MiB/s, write: 546.0 MiB/s
951: 2024-07-29 15:03:30 INFO:  51% (51.9 GiB of 100.0 GiB) in 58s, read: 900.0 MiB/s, write: 599.6 MiB/s
951: 2024-07-29 15:03:33 INFO:  53% (53.4 GiB of 100.0 GiB) in 1m 1s, read: 536.7 MiB/s, write: 439.3 MiB/s
951: 2024-07-29 15:03:37 INFO:  57% (57.9 GiB of 100.0 GiB) in 1m 5s, read: 1.1 GiB/s, write: 518.3 MiB/s
951: 2024-07-29 15:03:40 INFO:  61% (61.6 GiB of 100.0 GiB) in 1m 8s, read: 1.2 GiB/s, write: 536.2 MiB/s
951: 2024-07-29 15:03:44 INFO:  66% (67.0 GiB of 100.0 GiB) in 1m 12s, read: 1.3 GiB/s, write: 553.8 MiB/s
951: 2024-07-29 15:03:48 INFO:  72% (72.7 GiB of 100.0 GiB) in 1m 16s, read: 1.4 GiB/s, write: 343.9 MiB/s
951: 2024-07-29 15:03:51 INFO:  76% (76.5 GiB of 100.0 GiB) in 1m 19s, read: 1.3 GiB/s, write: 521.5 MiB/s
951: 2024-07-29 15:03:54 INFO:  80% (80.4 GiB of 100.0 GiB) in 1m 22s, read: 1.3 GiB/s, write: 401.7 MiB/s
951: 2024-07-29 15:03:57 INFO:  84% (84.2 GiB of 100.0 GiB) in 1m 25s, read: 1.3 GiB/s, write: 369.1 MiB/s
951: 2024-07-29 15:04:00 INFO:  88% (88.3 GiB of 100.0 GiB) in 1m 28s, read: 1.4 GiB/s, write: 524.9 MiB/s
951: 2024-07-29 15:04:03 INFO:  92% (92.3 GiB of 100.0 GiB) in 1m 31s, read: 1.3 GiB/s, write: 425.7 MiB/s
951: 2024-07-29 15:04:07 INFO:  99% (99.7 GiB of 100.0 GiB) in 1m 35s, read: 1.8 GiB/s, write: 12.3 MiB/s
951: 2024-07-29 15:04:14 INFO: 100% (100.0 GiB of 100.0 GiB) in 1m 42s, read: 41.6 MiB/s, write: 7.6 MiB/s

Anmerkung:
hdparm finde ich in den Ports nicht aber camcontrol soll laut man-page das ebenfalls können:
camcontrol apm [device id] [generic args] [-l level]

 

[mr44er]

Der smbd Prozess hatte zu dem Zeitpunkt 17G bzw. 12G reserviert.

Das ist brutal. Ich weiß jetzt aber nicht, ob es das reguläre Pufferverhalten von samba ist (RAM soll ja sinn"voll" benutzt werden, wenn er da ist) oder ob das sozusagen ein Notpuffer ist, weil die Platten mittendrin kurz aussteigen. Der Umkehrschluss wäre die 600GB in den RAM stopfen und dann in den swap und hoffen, dass der groß genug ist...das kann aber nicht im Sinne des Erfinders sein.

Die Resets/ASR Events hatte ich übersehen und ist merkwürdig

Checke mal jetzt die Werte ob die nach dem weiteren Test erneut hochgeklettert sind.

camcontrol soll laut man-page das ebenfalls können:

Jep, das kann das auch. Mit smartctl -s APM,255 oder so sollte das auch gehen, respektive -g (get) / -s (set).

 

[gadean]

Also die Werte bei Reset/ASR sind gleich geblieben.

Ich hatte jetzt APM deaktiviert und den Backup-Job 5x laufen lassen: keine Fehler
Aus Neugier haben ich APM wieder auf 128 gesetzt und lies das Backup ebenfalls 5x laufen: keine Fehler
In der gesamten Zeit ist Swap einmal auf 19% hoch gegangen und direkt wieder runter.

Es ist einfach zum verrückt werden, gefühlt spinnt meine gesamte Hardware diese Jahr und hat immer sporadische Fehler/Probleme

 

[mr44er]

Mhm...schwieritsch.
Ich harke nochmal zu dem APM-Krempel ein, etwas Hintergrund dazu schadet nicht und diese reset events sind für sich ganz ohne das Samba-Problem erforschungswert. Ich finde es wie gesagt seltsam, APM128 bei Platten mit enterprisenaher Firmware vorzufinden. Im Serverbereich ist eher 255, also ganz deaktiviert die Regel, weil man bei 24/7 Systemen mit z.B. Datenbanken und dauerhaft vielen Personen drauf keine zusätzlichen Latenzen erzeugen will (und dazu noch die Platten schneller verschleißt als nötig. Kopfparken ist sinnlos, wenn 2 Sekunden später wieder ein Zugriff erfolgt.)
Es kann sein, dass Toshiba diese Platten wirklich mit APM128 ausliefert, weil groß=automatisch eher Storagebereich und somit nicht automatisch Dauerzugriff.
APM128 für sich alleine macht normalerweise auch keine Probleme, es arbeitet ggf. nur gegen das Einsatzszenario. Dann stellt man das um und fertig, aber bei SATA muss man etwas genauer hinschauen. Live den Wert umschalten ist kein Problem, das geht immer, nur permanent abspeichern (-S, großes S) ist nicht garantiert. Wenn die Plattenfirmware das Abspeichern nicht erlaubt, überlebt diese Einstellung zwar einen Warmstart, aber keinen Kaltstart. Da hilft nur ausprobieren.
Noch dümmer wird es, wenn das Boardbios diese Werte jedes Mal neu setzt und das nicht klar kommuniziert wird.

Das aggressive LPM hier drückt den Platten ein niedriges APM auf und drosselt on top selbsttätig den SATA-Durchsatz. Unter Windows mag sowas klappen, bei allem anderen hagelt es Fehler.
Kann vorkommen, muss aber nicht. Kann für die Folgefehler bei Samba verantwortlich sein, muss aber nicht.
Ist es das nicht, könnte es noch das Netzteil sein...Alterserscheinungen z.B. oder auch an irgendeiner Stelle eine Überhitzung. Trat der Fehler eventuell erstmalig auf, als es generell warm wurde? Netzteile degradieren unter Hitze schneller, eine Überhitzung des SATA-Chips des Boards wäre auch denkbar.

Alles Nebelstocherei bis hierher und es ist ja bisher auch nicht geklärt, ob die resets weitere Auswirkungen haben/hatten oder ob Samba default soviel wegpuffert, bevor es ausschreibt.

 

[gadean]

Ich hab APM jetzt wieder auf 255/deaktiviert gesetzt und schaue die Tage ob es gespeichert wird, falls nicht hau ich das in @reboot cron rein.
LPM oder ähnliches habe ich bei mir im BIOS/EFI nicht gefunden, aber wer weiß

Netzteil sollte in Ordnung sein, ist aber immer schwierig zu verifizieren und nein ich denke nicht das es mit der Temperatur zusammenhängt, wir hatten vorher schon Tage an denen es erheblich wärmer war und auf die Kühlung der Komponenten achte ich verstärkt.

Aber wie du schon sagst, es ist alles Nebelstocherei, es kann Software oder Hardware sein, oder sogar eine Kombination?
Fürs erste probiere ich es mit dem APM und habe den ARC auf 32G limitiert, das werde ich erst mal so beobachten und parallel die Werte bei Resets/ASR überwachen.

Achja zum Thema Resets:
Könnte das mit "Stromausfällen" zusammenhängen?
Ich hatte vor längerer Zeit Probleme mit einer Sicherung und zu dem Zeitpunkt war die Kiste noch nicht an die UPS angeschlossen - war da noch am testen, ist aber schon länger her.

 

[mr44er]

Könnte das mit "Stromausfällen" zusammenhängen?
Ich hatte vor längerer Zeit Probleme mit einer Sicherung und zu dem Zeitpunkt war die Kiste noch nicht an die UPS angeschlossen - war da noch am testen, ist aber schon länger her.

Auch das "könnte", aber wieviele Ausfälle dieser Art braucht es, damit man bei derlei events dreistellig geloggt bekommt? Ich hatte in meinem Leben zu wenig Toshiba-Platten in der Hand, um das einstufen zu können. Bei HGST ist das definitiv "online" passiert, also bus reset und weiter gehts.
Normalerweise ist es der Wert:

192 Power-Off_Retract_Count -O--CK   100   100   000    -    23

ada2 23x Ausschaltvorgang ohne sanftes Kopfparken. Das wären dann die Stromausfälle und harte Abschaltungen.

Netzteil sollte in Ordnung sein, ist aber immer schwierig zu verifizieren

Man hängt ein anderes rein. Ist es das nicht, freut man sich über das Ersatzteil im Lager oder schickt es wieder zurück.
Für ~20€ gibts auch Testgeräte, ebenfalls eine sinnvolle Zukunkftsinvestition.

Fürs erste probiere ich es mit dem APM und habe den ARC auf 32G limitiert, das werde ich erst mal so beobachten und parallel die Werte bei Resets/ASR überwachen.

Schauen wir mal