MAM59

just plug your pc to the unraid server back to back. (if they are close enough to each other) Install the iperf3 docker on unraid before. you can start it from the shell later on

ok, then I would recommend you check the settings of "flow control". Usually there is no need for it with 1G slow-speed, but I think this 8225 is a very "special" device that produces a lot of grief to the people. You may also consider to get a "real nic" an put it into a slot. (As already said, I dont know this chip personally, I only have read the lots of complains here in the forum and am suspicious about them)

you are using this mysterious Realtek 8125 chip. As far as I know, 7.3.2 comes with its own driver for the chip now, but you install an plugin with a driver that overwrites the stock one. Try to disable this plugin and retest.

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...

Basically you have two configs that are fighting constantly who will be honored first. ETH0 and tailscale. both claim the rights to modify /etc/resolv.conf, so dnsmasq restarts every minute. turn off tailscale (for whatever it is good for???) and you should be done with the problem.

Ach DU warst das !!!🤣 (Scherz) Na ja, mit dem Alter schwinden Augen und Ohren, deshalb spar ich mir Atmos, die 5.1 Anlage ist abgeschaltet, ne schnöde Soundbar reicht nun. Die Nachbarn (nächstes Haus) haben die 2*300W Sinus Subwoofer nicht vermisst :-) Die Boxen hängen zwar noch im Wohnzimmer unter der Decke und in den Ecken, aber sind nicht mehr angeschlossen. Und "scharf" war eh gestern, meine Augen sehen keinen Unterschied zwischen 2k und 4k mehr. Also hab ich pragmatisch abgerüstet.

Na ja, Jellyfin streamt und hat die lokale Kontrolle über die benutzten Daten. Mein Kodi ist autonom und greift über SMB auf die einzelnen Shares zu. Ich bin kein Freund von Streaming, erstmal leidet die Qualität u.U. dramatisch, zweitens wird reichlich Energie beim Encoden verbraten. Ich encode einmal in ein geräteübergreifendes "MAM-Format" (*) (das sich im Laufe der Jahre schon mal ändern kann), welches ALLE Player abspielen können. Somit kein Bedarf an dauerndem Umkodieren. (Ausserdem ist der Platzbedarf um den Faktor 2-3 geringer :-) ) Nur vierstellig? Du Glücklicher :-) ich bin bei Filmen 5 stellig, bei Serienepisoden schon fast im 6 stelligen Bereich... Eben "70 Jahre Jäger & Sammler" :-) (*) = derzeit 1920x1080x25 H265 mit Dolby Digital 5.1 oder AAC Stereo. Ausnahmen sind in 4k, ältere HD Filme in 720p (werden ausgetauscht mit der Zeit), ein paar SD Leichen finden sich bestimmt auch noch irgendwo, aber wenn entdeckt, wird getauscht

Na ja, da sind verteilt Filme, Serien, Actor Pics usw drauf. Es ist etwas nervig, wenn man im Mediaplayer (Kodi) rumscrollt und dauernd bleibt er hängen, weil die jeweilige Platte erst hochfahren muß. Besonders die Akzeptanz von FRAUEN leidet darunter enorm. Also, alle auf einmal anwerfen, FRAU erziehen zu "beim Start kann es zu einer Pause von bis zu 30s kommen" und RUHE haben :-)

ich auch, wobei es nun deutlich schwieriger ist, das Problem zu erkennen, da man ja nie sagen kann, wann eine Platte im Schlafmodus sein sollte. Das fiel nur auf mit der Spinup Gruppe, da alle aus waren, nur die nicht.

Hmm, gute Frage, ich kann die Gruppe ja mal löschen und rebooten... dann dauerts wieder ein paar Tage und wir werden sehen. Oder soll ich den jetzigen Zustand erstmal beibehalten? Meine Hoffnung war ja, dass der fehlerhafte Status ein zufälliges Ereignis war und dass man dann später mit hdparm manuell (nach einmaligem Fehler probiert UNRAID es ja nie wieder) erzwingen kann. Aber, wie man sieht, trotz "OK" fährt die Platte nicht runter :-( Ist ja kein Beinbruch, im Notfall kann ich damit leben. Update: Dank fortgeschrittenem Alter ist die verbleibende Lebenszeit zu wichtig, um sie mit Warten zu verschwenden :-) Ich hab also die Startupgruppen deaktiviert und die Kiste neue gebootet (nun mit spindown auf 15min). Mal sehen, was passiert und wenn ja, wann...

So, nach 5 Tagen war es wieder so weit, disk 4 "klemmt" :-( Here we are again, after 5 days the drive is "stuck" again :-( Ich hab versucht, die spindown befehle von Hand zu geben, sie werden alle kommentarlos akzeptiert, aber die Platte fährt nicht runter. I have tried the spindown commands manually. All return 0 exit status, the drive does not spindown. root@F:~# /usr/sbin/hdparm -C /dev/sdf /dev/sdf: drive state is: idle root@F:~# /usr/sbin/hdparm -y /dev/sdf /dev/sdf: issuing standby command root@F:~# echo $? 0 root@F:~# /usr/sbin/hdparm -C /dev/sdf /dev/sdf: drive state is: standby root@F:~# echo $? 0 root@F:~# /usr/sbin/hdparm -S0 /dev/sdf /dev/sdf: setting standby to 0 (off) root@F:~# echo $? 0 root@F:~# Was nun? What to do next?