MAM59

if you go through walls consider to go to fiber too the same time. Copper is at the end of the line now

First of all: avoid Powerline and Wifi for servers AT ALL COSTS (though UNRAID now supports WiFi, its really a bad idea) Next: even more about DOUBLE Powerline DOUBLE WiFi or mixed Powerline/Wifi And of course, as what I have said already: SMB is bandwidth sensitive, iperf of course not. So iperf results may give a tendency but mean nothing for SMB at all. Why can't you use "normal" cables at least between UNRAID and the router???

Aaaaaaarrrr! :-☠️ Powerline is a non determinable kind of network. It does not guarantee ANY speed. And SMB is the worst you can run over it because, if SMB gets a "hic!" (small slowdown or cutoff) from the network, it instantly stops, halfs the speed and retries. If this happens often, every snail is faster than your transfer. On the other hand, if all goes well again it takes ages for SMB to step up to higher transfers again. Its a real loss-loss situation even worse if more than one powerline connection is on the way. Measurements of any kind are useless. Its purely random. At any means, try to switch to a more stable and determinable medium. Even WLAN today is better than powerline.

Sorry to correct you. Without DHCP present, both will fall back to APIPA(*) Addresses (169.254.x.x) and communications will be possible. So just plug and wait, then it will work (*) APIPA = Automatic Private IP Addressing

As we dont know (yet) if it is an issue at all, we also cannot say, it would be a non-issue. The controller may block certain requests (unraid pulls the disk status every second or so).

Aaaah! THAT might be the problem! The host adapter is slowing down the whole system this way (older versions may even not work correctly!), this also can result in network slowness! i Think, you may have the usual "too few PCIe lanes" problem with customer boards. The effects vary from "slow as a dog" to "card not recognized" to "only some disks work" you might need a lsi card with 4x only

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.