MAM59

overruns means "your computer was too busy to process the incoming packets fast enough. The input buffer of the nic was full (supposely it stopped transfers by sending out flow control packets if allowed to)" Nothing is lost, just slowed down alot. Watch your CPU load and eliminate time consuming stuff if possible. (or get better nics with larger buffers)

Still everything is working as it should be. The startup group spins down correctly, disk4 spins down on its own or if manually ordered to spin down. I guess, the only problem arises, if disk4 is part of the startup group, for whatever reason. Although strange, I think this problem is just here locally, I have to live with it. So I will stop further investigations now unless somebody has considerations for another test scenario that might help to pin down the culprit. @JorgeB ? ? ?

I agree, but I have monitored it over a long period now altready. It is totally reproducable here. At first, I thought it would be "always the last disk in the array", but a few months ago I have added another drive and now the "semi-last" disk (previous last one) is affected. I will turn on startup groups today again and watch when it happens once more Oh! I just had the idea of a different approach that MIGHT give new hints: I create a startup group I add ALL drives BUT the suspicious one (disk4) Then we will see: does a different drive show the same erratic behaviour? is disk4 still manually controllable ? Lets run it for a week and then rethink...

Simple, just create a startup group, put all array members including parity into that group and wait. After a few days, maybe a week or so, one drive starts to deny spindown. The only "visible" clue is that "status 1" returned by the spindown command and reported in the logs. Maybe it is just a timing problem, I guess, UNRAID tries to spindown all my 6 drives one by one in a loop and sets a timeout for the action. Maybe this one drive is sometimes too slow to react or something like that?!??!? maybe a simple "sleep 1" in the loop could help? (but I cannot find the loop, else I would test it)

Gut geraten :-) Ein Beispielfilmverzeichnis sieht so aus: root@F:/mnt/user/Filme/Animation# ls -lRva Ronal\ der\ Barbar\ \(2011\)/ Ronal der Barbar (2011)/: total 1568796 drwxrwxrwx 1 imagemaster users 29 Jan 11 2025 ./ drwxrwxrwx 1 nobody users 16384 Jul 2 06:02 ../ drwxrwxrwx 1 imagemaster users 34 Jan 10 2025 .actors/ -rwxrw-rw- 1 imagemaster users 1605901109 Mar 13 2023 Ronal\ der\ Barbar\ (2011).mkv* -rwxrw-rw- 1 imagemaster users 6227 Jan 10 2025 Ronal\ der\ Barbar\ (2011).nfo* -rwxrw-rw- 1 imagemaster users 196064 Jan 10 2025 Ronal\ der\ Barbar\ (2011)-fanart.jpg* -rwxrw-rw- 1 imagemaster users 318449 Jan 10 2025 Ronal\ der\ Barbar\ (2011)-poster.jpg* Ronal der Barbar (2011)/.actors: total 1396 drwxrwxrwx 1 imagemaster users 34 Jan 10 2025 ./ drwxrwxrwx 1 imagemaster users 29 Jan 11 2025 ../ -rwxrw-rw- 1 imagemaster users 674115 Jan 10 2025 Allan_Olsen.jpg* -rwxrw-rw- 1 imagemaster users 40800 Jan 10 2025 Anders_Juul.jpg* -rwxrw-rw- 1 imagemaster users 89553 Jan 10 2025 Bodil_Jørgensen.jpg* -rwxrw-rw- 1 imagemaster users 28746 Jan 10 2025 Brian_Lykke.jpg* -rwxrw-rw- 1 imagemaster users 117093 Jan 10 2025 Brigitte_Nielsen.jpg* -rwxrw-rw- 1 imagemaster users 25649 Jan 10 2025 César_Mourão.jpg* -rwxrw-rw- 1 imagemaster users 35103 Jan 10 2025 Dee_Snider.jpg* -rwxrw-rw- 1 imagemaster users 15665 Jan 10 2025 Hadi_Ka-Koush.jpg* -rwxrw-rw- 1 imagemaster users 27604 Jan 10 2025 Jens_Jacob_Tychsen.jpg* -rwxrw-rw- 1 imagemaster users 56608 Jan 10 2025 Jesper_Binzer.jpg* -rwxrw-rw- 1 imagemaster users 36785 Jan 10 2025 Lars_Bom.jpg* -rwxrw-rw- 1 imagemaster users 36384 Jan 10 2025 Lars_Mikkelsen.jpg* -rwxrw-rw- 1 imagemaster users 43292 Jan 10 2025 Lærke_Winther.jpg* -rwxrw-rw- 1 imagemaster users 19631 Jan 10 2025 Ole_Ernst.jpg* -rwxrw-rw- 1 imagemaster users 23445 Jan 10 2025 Ole_Thestrup.jpg* -rwxrw-rw- 1 imagemaster users 28116 Jan 10 2025 Preben_Kristensen.jpg* -rwxrw-rw- 1 imagemaster users 107999 Jan 10 2025 Sven-Ole_Thorsen.jpg* Es enhält also Film, NFO, Fanarts, Poster und ein UV ".actors" mit den Bildern der Beteiligten. Kodi "scraped" den Kram dann in eine zentrale MySQL Datenbank, die von allen Klienten benutzt wird. Aber ich bin ein Fan von KISS (keep it simple stupid!) und erhalte die Originaldaten damit auch andere Programme direkt damit arbeiten können und man Änderungen zur Not auch manuell vornehmen kann. Und ja, das ist eine "Glaubensfrage", ich glaube nicht an mysteriöse Datenbanken :-))) (Platte 4 geht immer noch brav aus, wenn ihr dazu geheissen wird :-) )

Ist auf allen Platten gleich, die Verzeichnisse auf Top Ebene haben alle denselben Zeitstempel. Keine Ahnung, wer oder was das macht. Mover? Cache_dirs? Es hindert die anderen Platten auf jeden Fall nicht daran, sich schlafen zu legen und im Moment (ohne Startupgruppen) ist auch disk4 brav, obwohl der Zeitstempel mit den anderen übereinstimmt. Mag sein, aber damit verzichtet man ja auf ein Hauptfeature von UNRAID: das DATENGRAB! Ich hab keine Lust, mich darum zu kümmern, WO eine Datei ist, ich werf sie einfach in die Freigabe, die Verteilung macht UNRAID. Und so ein- zweimal im Jahr lasse ich dann noch den großen Balancer drüberlaufen, damit die Platten symmetrisch ausgelastet werden (und nicht bis zum Rand, wo sie anfangen zu schnarchen). Und, wie schon öfters erwähnt, ich suche keinen Workaround, sondern einen Fix.

Ich kann ihr ja noch ne Woche Frist geben, das "Problem" existiert eh schon ein paar Jahre, da kommt es auf ein paar Wochen nicht an.

Das hat nix mit Arbeit zu tun, allerdings kommen mir diese Streaming Programme wie Jellyfin, Plex usw. nicht ins Haus. Ich scrape EINMAL und verlasse mich dabei nicht (nur) auf Daten aus dem Internet. Die Clients mit Kodis (meist Raspberries) brauchen nix tun, nur "lokale Infos" anzeigen. Spart endlose Ressourcen.

Aber das löst doch das Problem mit den Startupgruppen überhaupt nicht, es mag zwar für diesen speziellen Einsatzzweck die Zugriffe dämpfen, aber das kann mit anderen Anwendungen dann wieder anders aussehen. Filme & Serien sind ein Beispiel, auf dem Array liegt noch jede Menge anderer Kram rum. Fakt ist: Startupgruppen versprechen, dass alle zugehörigen Platten zur gleichen Zeit schlafen gehen und wieder auffwachen. Das funktioniert nicht korrekt offensichtlich. Also muss das jemand mal nachgucken und hoffentlich fixen.

immer noch ein ganz liebe, brave, Platte... Es liegt also definitv an den Stantupgruppen. Wie eskalieren wir das Problem nun weiter???

Das ist Absicht. Er soll ja als stummer Diener im Hintergrund den Dreck wegräumen. Da kommt es nicht auf Speed an, sondern auf Unauffälligkeit. Du sollst auf keinen Fall von seiner Arbeit behindert werden, deshalb zieht er sofort die Füsse ein, wenn sich im System etwas rührt. Ist also mehr am Schlafen, als am Kopieren.

doch, den gibt es schon. Wenn Du im "normalbetrieb" mal hier und da eine grosse Datei rüberschiebst (Backups / Videos usw) "schnupft" der Cache die dann locker weg (bei mir mit 10G LAN) Später kommt dann der Mover und schaufelt sie in aller Ruhe um auf das lahme Array. Der Cache fängt also die Peaks ab und schont Deine Nerven. Mich interessiert es schon, ob ich 3min auf einen Film warten muß oder ob die Sache in 30s gegessen ist (neue Filme werden immer vor dem Frühstück aufbereitet, gescraped und dann ins Array kopiert) Muss nur groß genug sein für die Laufdaten des Tages. Also ich komm locker mit 512Gb aus (weil ein Backup meines Arbeitsplatzes schon so an die 300Gb ranreicht) Aber, wenn die zu transferierende Datenmenge zu groß ist, wie bei einer Erstbetankung, dann ist der Cache kontraproduktiv.

Muss man erklären: Unraid zeigt bei CPU Last die IO Queue mit an, man kann also nicht sehen/sagen ob wirklich ein Kern ausgelastet ist, oder ob eine Plattenqueue voll ist und den Kopiertask suspendiert hat. Bei Massenkopieren ist es aber meistens die blockierende Platte (den Benefit von Turbowrite konnte ich in der Praxis noch nicht belegen. Der Unterschied ist nur "lahm" zu "ganz lahm". Es dauert auf jeden Fall Stunden und wenn man davor hockt, und wie ein Kaninchen auf die Schlange starrt, wird einem so oder so langweilig. Also: anwerfen und was anderes machen)

Würde auch MIT SSD wenig Sinn machen, denn irgendwann ("schneller als Du denkst") ist die SSD voll und dann passiert DAS GRAUEN! Also diese Massenaktionen besser OHNE Cache durchführen, das erscheint zwar langsam, aber ist im Endeffekt schneller, denn wenn die SSD voll ist, blockiert die Kiste komplett und je nach Mover Einstellungen dauert es Stunden, bis wieder einigermassen Fahrt aufgenommen werden kann. Glaub mit, das willst Du gar nicht miterleben... Ach ja, mach Dir keine Hoffnung auf >200Mb/s oder so. Ein UNRAID Array kommt selten über 60 MB/s. Das Schreiben der Parity zieht die Kiste echt runter. Ein Trick für die Massenbefüllung: Parity abschalten Daten kopieren (ohne Cache) Parity wieder einschalten/neu erstellen lassen Geht im Endeffekt meist deutlich schneller, als bei jedem Block die Parity nachführen zu lassen.

Zwischenbericht nach 3 Tagen (ohne Startupgruppen): Platte 4 geht immer noch ordnungsgemäß in Standby :-) Warten wir nochmal 3 Tage, dann kann man wohl mit an Sicherheit grenzender Wahrscheinlichkeit sagen, dass der Bug irgendwo in den Startupgruppen liegt...