February 6, 20251 yr Ich habe jetzt einiges umgebaut und inzwischen scheint das System wohl zu laufen. Was mich aber irritiert, dass bestimmte Laufwerke immer wieder aus dem Spindown aufwachen. Eingestellt sind 15 Minuten. Aber manche gehen immer wieder an, gehen dann wieder im Spindown und fahren dann wieder hoch. Und es sind immer die gleichen Platten. Manche bleiben aus. Verwenden tue ich ein Adaptec ASR-72405. Muss da evtl. was eingestellt werden? Vor allem sind einige der Platten die hochfahren komplett leer. Deshalb gibt es auch gar keinen Grund, dass die hochfahren sollten.
February 6, 20251 yr Schau mal ob du evl. ausversehen Docker Container drauf laufen hast. Ich habe ein SSD Pool da habe ich meine Docker Container drauf und den appdata Ordner. Diesen gebe ich dann immer bei der installation eines neuen Containers an als Datenordner. Wenn ich das mal vergesse und da steht z.B. /mnt/user/appdata würde ja auch in den gleichen Ordner schreiben aber dann geht mein Array auch nicht schlafen. Also gebe ich /mnt/cache/appdata an. Cache ist mein SSD Pool
February 6, 20251 yr Author 1 hour ago, mikiunraid said: Schau mal ob du evl. ausversehen Docker Container drauf laufen hast. Ich habe ein SSD Pool da habe ich meine Docker Container drauf und den appdata Ordner. Diesen gebe ich dann immer bei der installation eines neuen Containers an als Datenordner. Ist bei mir ähnlich. Aber von den 8 Platten die angehen, sind 6 leer. Da ist nichts drauf. Die Docker laufen auch alle im SSD Pool. Also appdata, domains, system. 1 hour ago, mikiunraid said: Wenn ich das mal vergesse und da steht z.B. /mnt/user/appdata würde ja auch in den gleichen Ordner schreiben aber dann geht mein Array auch nicht schlafen. Also gebe ich /mnt/cache/appdata an. Das heißt das funktioniert bei dir nur, wenn du den SSD Pool direkt zuweist, auch wenn appdata ohnehin im Pool liegt und auch kein mover hinterlegt ist?
February 6, 20251 yr Quote Das heißt das funktioniert bei dir nur, wenn du den SSD Pool direkt zuweist, auch wenn appdata ohnehin im Pool liegt und auch kein mover hinterlegt ist? Ja so ist es
February 6, 20251 yr Author Ich habe jetzt mal alle Docker beendet und auch eine VM läuft nicht. Das heißt es ist nichts aktiv, was ggf. auf ein Share und damit auf die Disks zugreifen könnte. Dennoch das gleiche Problem. Die bestimmten gleichen Platten, auch leere, fahren immer wieder hoch. Manche bleiben aber aus. Edited February 6, 20251 yr by Cannon
February 6, 20251 yr Sind das die Platten die am ASR-72405 hängen? Oder hängen alle Platten bei dir am ASR-72405?
February 6, 20251 yr Author 37 minutes ago, mikiunraid said: Sind das die Platten die am ASR-72405 hängen? Oder hängen alle Platten bei dir am ASR-72405? Alle Platten hängen am ASR-72405. Sonst wäre das Problem sicherlich leichter zu lösen gewesen.
February 6, 20251 yr Author Ich habe mal den Log aufgemacht. Sieht lustig aus, warum die angehen: Feb 6 16:07:01 Tower emhttpd: spinning down /dev/sdx Feb 6 16:07:29 Tower emhttpd: spinning down /dev/sdp Feb 6 16:07:44 Tower emhttpd: spinning down /dev/sdo Feb 6 16:07:58 Tower emhttpd: spinning down /dev/sdk Feb 6 16:08:09 Tower emhttpd: spinning down /dev/sdq Feb 6 16:08:22 Tower emhttpd: spinning down /dev/sdr Feb 6 16:08:52 Tower emhttpd: spinning down /dev/sdi Feb 6 16:09:11 Tower emhttpd: spinning down /dev/sdg Feb 6 16:10:37 Tower emhttpd: read SMART /dev/sdx Feb 6 16:11:07 Tower emhttpd: read SMART /dev/sdp Feb 6 16:11:21 Tower emhttpd: read SMART /dev/sdo Feb 6 16:11:33 Tower emhttpd: read SMART /dev/sdk Feb 6 16:11:45 Tower emhttpd: read SMART /dev/sdq Feb 6 16:11:59 Tower emhttpd: read SMART /dev/sdr Feb 6 16:12:29 Tower emhttpd: read SMART /dev/sdi Feb 6 16:12:49 Tower emhttpd: read SMART /dev/sdg Feb 6 16:25:31 Tower emhttpd: spinning down /dev/sdx Feb 6 16:25:58 Tower emhttpd: spinning down /dev/sdp Feb 6 16:26:15 Tower emhttpd: spinning down /dev/sdo Feb 6 16:26:27 Tower emhttpd: spinning down /dev/sdk Feb 6 16:26:39 Tower emhttpd: spinning down /dev/sdq Feb 6 16:26:52 Tower emhttpd: spinning down /dev/sdr Feb 6 16:27:21 Tower emhttpd: spinning down /dev/sdi Feb 6 16:27:42 Tower emhttpd: spinning down /dev/sdg Feb 6 16:29:07 Tower emhttpd: read SMART /dev/sdx Feb 6 16:29:37 Tower emhttpd: read SMART /dev/sdp Feb 6 16:29:51 Tower emhttpd: read SMART /dev/sdo Feb 6 16:30:03 Tower emhttpd: read SMART /dev/sdk Feb 6 16:30:15 Tower emhttpd: read SMART /dev/sdq Feb 6 16:30:28 Tower emhttpd: read SMART /dev/sdr Feb 6 16:30:59 Tower emhttpd: read SMART /dev/sdi Feb 6 16:31:19 Tower emhttpd: read SMART /dev/sdg Also der fährt die immer wieder runter und nach 3-4 Minuten will der die SMART-Parameter lesen und die gehen wieder an. Das ist doch wirklich etwas unsinnig. Wie kann ich das denn verhindern?
February 6, 20251 yr 1 hour ago, Cannon said: nach 3-4 Minuten will der die SMART-Parameter lesen und die gehen wieder an. Sieht zwar so aus ist aber in Wirklichkeit genau andersherum. Die Platten laufen an und daraufhin werden die smart Werte abgefragt. Irgendetwas anderes weckt deine Platten auf. Entweder es ist tatsächlich der Controller selbst oder irgendein Plugin?!
February 6, 20251 yr 1 hour ago, Cannon said: Ich habe mal den Log aufgemacht. Sieht lustig aus, warum die angehen: häng doch mal eher ne diagnostics ran ...
February 6, 20251 yr 6 hours ago, mikiunraid said: Wenn ich das mal vergesse und da steht z.B. /mnt/user/appdata würde ja auch in den gleichen dafür gibt es exclusive Shares das man 6 hours ago, mikiunraid said: Also gebe ich /mnt/cache/appdata an. genau dies nicht mehr benötigt ...
February 6, 20251 yr Author 49 minutes ago, jj1987 said: Sieht zwar so aus ist aber in Wirklichkeit genau andersherum. Die Platten laufen an und daraufhin werden die smart Werte abgefragt. Irgendetwas anderes weckt deine Platten auf. Entweder es ist tatsächlich der Controller selbst oder irgendein Plugin?! Ja verstehe ich auch nicht. Ein Plugin würde ich ausscließen. Da ist nichts aktives. 26 minutes ago, alturismo said: dafür gibt es exclusive Shares das man Meint das, dass die keinen Secondary storage haben und nur im Pool liegen? Oder ist damit was anderes gemeint? 29 minutes ago, alturismo said: häng doch mal eher ne diagnostics ran ... Ist dran. Was mir schon aufgefallen ist, dass der bei der parity da am Ende steht DISK_INVALID. Das hat aber sicher seinen Grund, weil das ja keine normale Datendisk ist. tower-diagnostics-20250206-1841.zip
February 6, 20251 yr 38 minutes ago, Cannon said: Meint das, dass die keinen Secondary storage haben und nur im Pool liegen? Oder ist damit was anderes gemeint? das was dazu in der Dokumentation steht (ja, sowas gibt es ) https://docs.unraid.net/unraid-os/release-notes/6.12.0/#exclusive-shares
February 6, 20251 yr 41 minutes ago, Cannon said: Ist dran. Was mir schon aufgefallen ist, dass der bei der parity da am Ende steht DISK_INVALID. Das hat aber sicher seinen Grund, weil das ja keine normale Datendisk ist. Mann Mann ... DU schreibst das in ein go file und wunderst dich ... manchmal macht mich das hier fertig
February 6, 20251 yr Author 1 minute ago, alturismo said: manchmal macht mich das hier fertig Das sollte ich so machen. Das hat mir DataCollector so empfohlen, damit der Schreibcache an ist: Entschuldige, dass ich doof Frage, was hat denn er Cache damit zu tun?
February 6, 20251 yr So ich habe meine appdata Freigabe auch mal umgestellt (siehe Bild) Vorher hatte ich anstatt Cache Array da stehen. Jetzt bleiben meine Platten auch nicht mehr im Schlafanzug.
February 6, 20251 yr 1 minute ago, Cannon said: Das sollte ich so machen. Das hat mir DataCollector so empfohlen, damit der Schreibcache an ist: naja, du hast spinups, du siehst perm smartctl, das kannst du mal erwähnen ... ansonsten, deine Shares sehen alle ok aus (2 Stück existieren nicht "mehr", evtl. die config files entfernen) wahrscheinlich "Altlasten" appdata shareUseCache="only" # Share exists on cache a-----e shareUseCache="yes" # Share exists on disk2 a--------s shareUseCache="yes" # Share exists on disk1 b----p shareUseCache="yes" # Share exists on cache, disk2 d----------s shareUseCache="yes" # Share exists on disk2 domains shareUseCache="only" # Share exists on cache isos shareUseCache="yes" # Share exists on disk2 k-----e shareUseCache="yes" # Share exists on disk1 m----s shareUseCache="yes" # Share exists on disk1 m---c shareUseCache="yes" # Share exists on disk1 m----------s shareUseCache="yes" # Share exists on disk1 N--------r shareUseCache="no" # Share does not exist p----s shareUseCache="yes" # Share exists on disk2 r----------s shareUseCache="yes" # Share exists on disk2 s----s shareUseCache="yes" # Share exists on disk1 s-------g shareUseCache="only" # Share exists on cache system shareUseCache="only" # Share exists on cache t----------s shareUseCache="yes" # Share exists on disk2 t--p shareUseCache="yes" # Share exists on disk2 t---------g shareUseCache="only" # Share does not exist v----s shareUseCache="yes" # Share exists on disk2 x----s shareUseCache="yes" # Share exists on disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10 du hattest auch gestern 12500 Zeilen Fehleinträge hierzu ... was spezielles da gemacht ? Feb 5 15:32:56 Tower nginx: 2025/02/05 15:32:56 [crit] 11444#11444: ngx_slab_alloc() failed: no memory Feb 5 15:32:56 Tower nginx: 2025/02/05 15:32:56 [error] 11444#11444: shpool alloc failed Feb 5 15:32:56 Tower nginx: 2025/02/05 15:32:56 [error] 11444#11444: nchan: Out of shared memory while allocating message of size 15714. Increase nchan_max_reserved_memory. Feb 5 15:32:56 Tower nginx: 2025/02/05 15:32:56 [error] 11444#11444: *123412 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Feb 5 15:32:56 Tower nginx: 2025/02/05 15:32:56 [error] 11444#11444: MEMSTORE:01: can't create shared message for channel /disks dann hast du folgendes plugin am Start file.activity.plg - 2025.01.21 (Up to date) auch das mal runter, macht nur Sinn wenn man Traffic debuggen will, wenn aber alles off ist (Docker, VM's, plugins, scripts) dann kann kein File auf sein.
February 6, 20251 yr 8 minutes ago, mikiunraid said: So ich habe meine appdata Freigabe auch mal umgestellt (siehe Bild) Vorher hatte ich anstatt Cache Array da stehen. Jetzt bleiben meine Platten auch nicht mehr im Schlafanzug. du hast hoffentlich auch vorher alles rüber kopiert ... von alleine passiert das nicht ... und wenn man es richtig machen will, siehe Link oben zu exclusive Shares (um den FUSE overhead zu umgehen"
February 6, 20251 yr Author 4 minutes ago, alturismo said: naja, du hast spinups, du siehst perm smartctl, das kannst du mal erwähnen ... Sorry, ich wusste nicht, was ich tue. Deshalb besonderen Dank für die Mühe und Geduld! 14 minutes ago, alturismo said: hol das mal raus und starte dann neu Mache ich wenn der Paritycheck morgen durch ist mit den letzten 3 Disks. 8 minutes ago, alturismo said: ansonsten, deine Shares sehen alle ok aus (2 Stück existieren nicht "mehr", evtl. die config files entfernen) wahrscheinlich "Altlasten" Ja hießen dann sowas wie "New folder". Ist jetzt weg. 9 minutes ago, alturismo said: du hattest auch gestern 12500 Zeilen Fehleinträge hierzu ... was spezielles da gemacht ? Ich hatte Problem mit dem Parity check. Da ging dann nix mehr. Das ganze System hing. War ein Hardwareproblem, der Powerstecker an einem der HD-Arrays, war nicht fest genug und löste sich nach mehreren Stunden. Ich vermute das war das Problem. 10 minutes ago, alturismo said: dann hast du folgendes plugin am Start file.activity.plg - 2025.01.21 (Up to date) Hatte ich auf Grund der Spinup-Probleme rauf gemacht. Aber ist auch deaktiviert und wieder entfernt. 11 minutes ago, alturismo said: wenn aber alles off ist (Docker, VM's, plugins, scripts) dann kann kein File auf sein Die Docker liefen dann wieder, nachdem die Probleme sich damit nicht gelöst haben. Die VM arbeitet aktuell erst mal woanders, bis die Maschine fehlerfrei läuft. Die Docker und der Rest soll aber weiter laufen. Ich lasse mich dann morgen überraschen, ob alles läuft.
February 6, 20251 yr 1 minute ago, Cannon said: Mache ich wenn der Paritycheck morgen durch ist mit den letzten 3 Disks. 14 minutes ago, alturismo said: wenn du dir sicher bist das nichts geschrieben wurde, kann man den auch getrost abbrechen ... teste dann mal neu und wenn es immer noch hängt, bitte neue diags ... die machen anhand der tausenden Zeilen nicht wirklich Spaß zum debuggen.
February 6, 20251 yr Author 2 minutes ago, alturismo said: wenn du dir sicher bist das nichts geschrieben wurde, kann man den auch getrost abbrechen ... Nee der dauert auch schon so 3 Tage. Ich hoffe dann das der das der ERSTE MAL durch ist. Ich meine auch Parity-Sync. Edited February 6, 20251 yr by Cannon
February 6, 20251 yr Community Expert 1 hour ago, alturismo said: Mann Mann ... DU schreibst das in ein go file und wunderst dich ... ... manchmal macht mich das hier fertig Adaptec Series 7 hat unter unraid ab und zu Probleme den Cache zu deaktivieren. Mit dem Befehl (den mgutt vor Jahren für mich ausgegraben hat) ist das Problem weg. Siehe auch hier: https://forums.unraid.net/topic/117696-solved-writecache-laesst-sich-nicht-wieder-einschalten-bis-heute-morgen-war-er-wohl-aktiv/#findComment-1077697 und hier: https://forums.unraid.net/topic/142191-6115-hba-settings-änderung-führte-zu-unmountable-unsupported-partition-layout-update-hdd-zu-unassigns-daten-wieder-da-wtf/#findComment-1284890 Aber meine Disks in dem System bleiben alle schlafen/Spindown, wenn sich nichts tut. An dem Befehl kann es nicht liegen.
February 6, 20251 yr Community Expert 1 hour ago, Cannon said: Nee der dauert auch schon so 3 Tage. Ich hoffe dann das der das der ERSTE MAL durch ist. Ich meine auch Parity-Sync. Paritycheck >3 Tage? Mein Paritycheck mit 26 Disks (2P+24D) hat nicht so lange gedauert. 20 der Disks im Array hängen an meinem Adaptec, 6 direkt am Mainboard. Mein Array nutzt 22TB, 20TB und 18TB Disks.
February 6, 20251 yr Author 1 hour ago, DataCollector said: Paritycheck >3 Tage? Vielleicht etwas übertrieben. Laut Schätzung von Unraid aktuell noch 5,5 h, dann sind wir bei insgesam 1 Tag und 18 h. 1 hour ago, DataCollector said: Aber meine Disks in dem System bleiben alle schlafen/Spindown, wenn sich nichts tut. An dem Befehl kann es nicht liegen. Da sind dann nun die Hoffnungen dahin. Ich probiere das dennoch mal. Irritierend ist, dass es immer die gleichen Disks sind, die online gehen. Vor allem hängt es auch nicht mit dem Kanal am Adaptec zusammen, woran die hängen.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.