Festplatte kann nicht heruntergefahren werden

[RedZero]

Hallo, ich hab zu dem Thema hier im Forum schon rumgesucht aber nichts dazu gefunden was mir helfen kann.

Und zwar kann wie im Titel schon steht ich meinen Datenträger 1 nicht herunterfahren bzw wenn ich draufklicke lädt er kurz bleibt dann aber grün.

zu meinem System ich habe nur zwei Festplatten einmal den Datenträger 1 und einen Paritätsdatenträger sowie ein Pool device als Flash Speicher.

Ich habe schon Appdata und System auf den Cache im Pool Device ausgelagert und auch soweit alle Freigaben die öfters benutzt werden auch auf den Cache ausgelagert und mit Mover in der Nacht auf die HDD übertragen.

Verzögerung beim Herunterfahren steht auf 30 Minuten

Ich habe keine Schreibzugriffe auf den Datenträger 1 und auch mit lsof und File activity konnte ich keine Prozesse finden die auf der Disk1 laufen.

Hat da jemand eine Idee?

[Pete0]

Hast du irgendwelche Docker am Laufen, die ggfs. auf einen Share zugreifen. Ich hatte z. B. das Thema mit dem Nextcloud-Docker. Ab einer bestimmten Version wurde die Festplatte, auf dem der Share für Nextcloud liegt, nicht mehr runtergefahren.

 

Kannst du hören, dass die Festplatte in den Spin-Down geht und paar Sekunden später wieder startet? Oder fährt es gar nicht erst runter?

Was für Platten sind es?

[DataCollector]

21 minutes ago, RedZero said:

Und zwar kann wie im Titel schon steht ich meinen Datenträger 1 nicht herunterfahren bzw wenn ich draufklicke lädt er kurz bleibt dann aber grün.

 

Bitte prüfe bei den Shares mal mit dem Button compute all, ob da nicht doch noch ein Systemshare auf der betreffenden Disk schlummert.

(ggf. den Screenshot nach dem "compute all" hier mal zeigen).

 

Zusatzfrage: Ist die betreffende Festplatte ein SAS, ein SATA oder gar ein über USB angeschlossenes Modell?

[RedZero]

10 hours ago, DataCollector said:

 

Bitte prüfe bei den Shares mal mit dem Button compute all, ob da nicht doch noch ein Systemshare auf der betreffenden Disk schlummert.

(ggf. den Screenshot nach dem "compute all" hier mal zeigen).

 

Zusatzfrage: Ist die betreffende Festplatte ein SAS, ein SATA oder gar ein über USB angeschlossenes Modell?

Hab mal den Screenshot angehängt, ja es sind USB Festplatten, komischerweise hat es ja mit dem runterfahren vor ein paar Tagen geklappt als ich nur eine Festplatte angeschlossen hatte aber seit ich die Paritätsfestplatte habe geht nur noch die nach der eingestellten Zeit in den Schlafmodus.

[RedZero]

11 hours ago, Pete0 said:

Hast du irgendwelche Docker am Laufen, die ggfs. auf einen Share zugreifen. Ich hatte z. B. das Thema mit dem Nextcloud-Docker. Ab einer bestimmten Version wurde die Festplatte, auf dem der Share für Nextcloud liegt, nicht mehr runtergefahren.

 

Kannst du hören, dass die Festplatte in den Spin-Down geht und paar Sekunden später wieder startet? Oder fährt es gar nicht erst runter?

Was für Platten sind es?

Alle Docker befinden sich im Cache und haben keine Daten auf dem Array, nur Paperless ngx nutzt für seine Dokumentenablage die HDD als sekundären Speicher aber solange ich Paperless nicht öffne macht der keine zugriffe auf seine abgelegten Daten. Ich hab vielleicht noch vergessen zu erwähnen das der Paritätsdatenträger problemlos in den Schlafmodus geht nur mein Hauptdatenträger halt nicht.

Wenn ich auf den grünen Punkt drücke dann lädt er kurz aber er bleibt grün.

[DataCollector]

Folgende Shares sehe ich als Systemshares an:

 

"appdata" die Stelle wo standardmäßig die Docker laufen.
"domains" enthält die Virtuiellen Disks für VM
"isos" ist nur ein Lagerplatz für Isodateien
"system" enthält docker und libvirt images

 

Dein Appdata liegt (auch) auf Disk1
Deine domains liegt exklusiv auf Disk1
Deine Isos liegen exklusiv auf Disk1
Dein system liegt (auch) auf Disk1

 

Wie soll die Disk 1 sich schlafen legen, wenn die Systemzugriffe ständig auf dies eintrommeln?

Da die Parität sich ja Deiner Aussage nach schlafen legt sind die stattfindenden Zugriffe lesender Natur.

 

Zu USB - Spindown: Ob eine Festplatte darin schlagen geschickt werden kann hängt auch von dem Kontroller des USB-SATA Gehäuses ab. Da kann unraid selber dann auch nichts mehr machen.

 

Zu USB im Array generell: wird nicht empfohlen. ist häufig ein Quell der "Freud.... Probleme".  Besser nicht nutzen.

 

Edited March 6 by DataCollector
Typos

[RedZero]

3 hours ago, DataCollector said:

Folgende Shares sehe ich als Systemshares an:

 

"appdata" die Stelle wo standardmäßig die Docker laufen.
"domains" enthält die Virtuiellen Disks für VM
"isos" ist nur ein Lagerplatz für Isodateien
"system" enthält docker und libvirt images

 

Dein Appdata liegt (auch) auf Disk1
Deine domains liegt exklusiv auf Disk1
Deine Isos liegen exklusiv auf Disk1
Dein system liegt (auch) auf Disk1

 

Wie soll die Disk 1 sich schlafen legen, wenn die Systemzugriffe ständig auf dies eintrommeln?

Da die Parität sich ja Deiner Aussage nach schlafen legt sind die stattfindenden Zugriffe lesender Natur.

 

Zu USB - Spindown: Ob eine Festplatte darin schlagen geschickt werden kann hängt auch von dem Kontroller des USB-SATA Gehäuses ab. Da kann unraid selber dann auch nichts mehr machen.

 

Zu USB im Array generell: wird nicht empfohlen. ist häufig ein Quell der "Freud.... Probleme".  Besser nicht nutzen.

 

Appdata und System liegen nicht auf Disk1 bzw diese 6byte sind irgendwelche Reste die ich jetzt auch per Terminal gelöscht hab, Domains und Isos sind Leer bzw auch nur diese 6 byte.

Ich hab dir mal ein Bild angehängt wie die Lese und Schreibzugriffe fast die ganze Zeit bei mir ausschauen.

Kann ich irgendwie feststellen ob wie du sagst evtl das SATA USB Gehäuse nicht unterstützt? weil sonst geb ich die zurück und hol mir nochmal die selbe.

[DataCollector]

8 hours ago, RedZero said:

Appdata und System liegen nicht auf Disk1

 

doch

Screenshot von Deinem Bild unten (mit roter Kennzeichnung ergänzt).

 

8 hours ago, RedZero said:

bzw diese 6byte sind irgendwelche Reste die ich jetzt auch per Terminal gelöscht hab,

 

Solange die Verzeichnisse dort verbleiben, läuft die Disk mit an/bleibt wach

 

8 hours ago, RedZero said:

Domains und Isos sind Leer bzw auch nur diese 6 byte.

 

Es ist egal ob darin etwas liegt oder nicht.

Fuse muss nachsehen, ob da zwischenzeitlich etwas gelandet ist, wenn der Share angefragt wird.

 

8 hours ago, RedZero said:

Ich hab dir mal ein Bild angehängt wie die Lese und Schreibzugriffe fast die ganze Zeit bei mir ausschauen.

 

Ich sehe kein solches Bild in dem Beitrag.

 

8 hours ago, RedZero said:

Kann ich irgendwie feststellen ob wie du sagst evtl das SATA USB Gehäuse nicht unterstützt?

 

Ja, indem Du das Laufwerk eben versuchst herunter zu fahren, wenn Du Lese- und Schreibzugriffe  gaaaaaaaanz sicher ausschließen kannst (alle Systemshares von dem Laufwerk entfernst/auf den Cache/Pool verschiebst).

Alternativ das Laufwerk nicht im Array, sondern mal als UD verbinden und dann runter fahren.

 

8 hours ago, RedZero said:

weil sonst geb ich die zurück und hol mir nochmal die selbe.

 

... Um dann bei dem selben Konfigurationsfehler das selbe Verhalten zu erleben und es wieder auf das Laufwerk zu schieben?

 

 

Die Systemshares liegen (laut dem Screenshot in dem vorvorherigen Beitrag) sehr wohl auf der Disk 1 und somit ist das Fuse Dateisystem immer gezwungen auch auf der Disk 1 nachzusehen, ob da etwas liegt, wenn eine Anfrage an den Share gestellt wird. (schliesslich ist es ein Netzwerk verbundenes System und es kann immer/jederzeit irgendetwas hintenrum durch SMB oder Docker oder VM oder direkt von unraid da rein geschoben/verändert  worden sein.)

 

Egal ob da nur eine 6 Byte große Datei liegt oder das Verzeichnis sogar leer ist.

 

Du kannst Zugriffe reduzieren, indem Du mit dem Plugin "Cache Dirs" den Zustand im Ram zwischenspeicherst, aber dennoch: wenn die Disk 1 schlafen soll, entferne zumindest die Systemshares von der Disk.

 

Edited March 6 by DataCollector
Typos