mgutt

1 means something like "enabled" ("Samba will read from files asynchronously when the request size is bigger than this value") and 0 disabled. That's why I said aio max threads. This setting seems to have a different influence: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#AIOMAXTHREADS

Ok, yes. The reason could be the aio max threads setting. Its default is 100. So using an HDD as target, which has a bad I/O performance, could slow down the transfer. I think a better solution would be to test a smaller aio max threads value and if it solves the issue, I would suggest to use the small value by default and the higher value is set, after the user added a cache pool. It still means a reduced performance for HDD transfers, but I think those users won't do this often. Or it will be added as an option to the SMB settings (as SMB Multichannel should be as well).

We have a similar discussion in the German forums and we have multiple users with full speed while using user shares: https://forums.unraid.net/topic/113345-smb-leistung-mangelhaft/?tab=comments#comment-1031606 At the moment we are not sure if this is related to specific NICs or the new Unraid version. aio read size = 1 aio write size = 1 Why is this disabled in smb.conf of Unraid? Regarding my tests this option reduces performance if disabled. So I would say it should be enabled by default and not only for SMB Multichannel scenarios. PS You did not mention in the blog article that SMB Multichannel alone does not work. The adapters on both sides need RSS support. Else you don't benefit from Multichannel from a single 10G connection (but if you use multiple 10G connections). RSS is auto-detected since Samba 4.13, so Unraid 6.10 is a requirement. More details in my Guide: There are two different things to know: 1.) SMB Multichannel enables transfers across multiple channels. This means if you have multiple ethernet ports in the same ip range, SMB automatically splits a file transfer and use all ports at the same time. By that its possible to connect a server with two 1G ports and a client with one 2.5G and transfer with ~200MB/s. 2.) The next point is RSS (receive side scaling). RSS allows to split transfers across multiple cpu cores. By that the a 10G transfer does not hit the cpu core limit which bottlenecks the transfer speed. As an SSD is faster in writing multiple threads, even 1G connections will benefit a little bit. Note: RSS works only if the network adapter supports it on both sides and multichannel is enabled. RSS will slow down transfer speeds if the target is a HDD. So consider installing more RAM and raising "vm.dirty_ratio" if you like to transfer directly to HDDs. So what does it mean for your scenario: It depends. Lets say your server and client both use 2.5G. Then enabling SMB Multichannel alone wouldn't enhance the transfer speeds. But if both support RSS, the transfers will be split across multiple cores and so you benefit a little bit from parallel writes to your SSD, which can be more useful if you transfer very much tiny files. Or let's say our server has two 1G connections and your client 2.5G. Then enabling SMB Multichannel will boost the transfer to ~200MB/s. In this scenario RSS is not needed. PS I tested this scenario with 2x 1G (server) and 1x 10G (client) and it worked only after I disabled RSS on the client side as my servers ethernet adapters did not support RSS (mixed scenarios are not allowed!).

Yes, I tested everything and the only difference I found was "aio write size" must be enabled and "write cache size" should be not zero. But write cache size has been already removed in Samba 4.12 because io_uring became the default: https://wiki.samba.org/index.php/Samba_Features_added/changed#REMOVED_FEATURES_3 PS Unraid 6.9.2 uses already Samba 4.12.14 Yes. And another important change with Samba 4.13 is the auto detection of RSS. So maybe since Unraid 6.10 we don't need this line anymore: interfaces = "10.10.10.10;capability=RSS,speed=10000000000" So finally we only need to enable SMB Multichannel and everything should be perfectly running.

Also er meint, dass man nur vom mittleren Käfig den unteren HDD Slot wegen dem ATX Stecker frei lassen müsste. Ansonsten denkt er, dass es passt. Dann ginge es sogar bis Full ATX. Da fragt man sich, warum der Hersteller so ein Case nicht selbst anbietet.

Du kannst nicht nach /mnt/user kopieren, da das die Summe aus NVMe und Disk ist. Du kannst nur von /mnt/nvmeX nach /mnt/diskX kopieren und um genau zu sein, solltest nicht du, sondern der Mover das machen. Allerdings hast du ein Problem. Du hast mit dem Mover die Daten verschoben, während der Cotnainer ausschließlich auf den Cache zugreifen konnte. Dh du hast jetzt vermutlich teilweise die selben Dateien auf dem Cache und den Disks. In so einer Situation müsste man eigentlich schon hingehen und seine Backups nutzen, da du ja nicht mehr weißt welchen Dateien man trauen kann. Wenn es das nicht geben sollte, müsstest du Docker und VM auf No setzen, den Mover arbeiten lassen und die Logs prüfen bzw den Inhalt der SSD. Sind dann noch Daten übrig, weil sie auf Cache und Disk doppelt vorhanden sind, musst du die schwere Entscheidung fällen, ob du die "alten" Dateien von den Disks nimmst und die vom Cache löschst oder von Hand die Dateien vom Cache auf die Disks verschiebst und die auf den Disks überschreibst. Als du die Pfade auf /mnt/user geändert hast, wurden übrigens die vom Cache verwendet. Also lass den Mover mal arbeiten und dann schaust du ob was übrig bleibt. Denk dran: Solange der Cache nicht leer ist und nicht alle Pfade korrigiert wurden, darfst du Docker und VM nicht auf Yes stellen. Und ja, wenn er leer ist, darfst du den Cache auf No stellen.

Ein paar deiner Container nutzen nicht /mnt/user sondern /mnt/cache als Pfad? Hattest du mal den Cache auf No oder Only gestellt? Das erklärt solche Probleme. Der Container findet dann seine Dateien nicht mehr und installiert sich neu.

Bug gemeldet:

Da system und Domain noch vorhanden ist, war VM und Docker nicht deaktiviert. Denk dran, nicht nur Container stoppen, sondern den Dienst deaktivieren. Appdata ist nicht gesund, dass das noch da ist. Das deutet daraufhin, dass du Dateien darin bereits auf dem Array hast. Prüf mal ob die Dateien in dem Ordner bereits auf der Disk existieren.

Does the Forum Software allow auto linking specific words? I would like to see "Diagnostics" automatically linked to the specific section in the Wiki. Another usefull auto link could be "scrub".

In /mnt/cache? Und wenn du über die GUI den Inhalt von /mnt/cache sichtest, dann siehst du nichts? Screenshots und Diagnostics bitte.

Mach das bitte mal mit Prefer. Ich habe das eben getestet. Hat nichts von der Disk auf den Cache bewegt.

Hast du den Inhalt der SSD gesichtet? Das Dateisystem belegt auch ohne Dateien Platz. Wenn keine Dateien drauf sind, ist sie auch leer. Welches Verzeichnis sichtest du mit WinSCP? Du hast da ein Verständnisproblem. Der Mover kann NUR bei Yes vom Cache aufs Array verschieben. Das geht bei keiner anderen Option.

Du hast tatsächlich einen Bug gefunden. Ich habe das gerade getestet und der Mover steigt aus, wenn ein Sharename ein Leerzeichen enthält. Erstaunlich, dass das vorher noch keinem aufgefallen ist.

Löschen und dann testen Tools > System Logs

Aktiviere die Mover Logs und schau nach dem Pfad, den er verschieben sollte. Er muss ja irgendwelche Fehler ausgeben.

Du hattest doch SMR Platten im RAID oder? Dann hast du deine Antwort. Lesen, vergleichen und an der selben Stelle korrigieren, mag SMR überhaupt nicht.

Komisch, weil schlussendlich müssen ja beide einen FAT formatierten Stick erstellen. Eventuell ein USB Problem bei deinem Windows PC?!

Welcher deiner Container verwendete healthcheck?

Nach ein bisschen Recherche würde ich sagen defekter Stick oder defekter RAM. https://forums.unraid.net/topic/61831-kernel-panic-not-syncing-vfs-unable-to-mount-root-fs/ https://forums.unraid.net/topic/62485-solved-kernel-panic-not-syncing-vfs-unable-to-mount-root-fs-on-unknown-block00-and-random-system-lock-ups-once-running/ https://forums.unraid.net/topic/96169-kernel-panic-not-syncing-vpf-unable-to-mount-root-fs-on-unknown-block-solved/

Ah ok. Hier auf dem Foto sieht man es etwas besser. Ich denke der Schraubpunkt ist der wo normalerweise mATX hinreicht. Ich sag mal so. Wenn man auf 4 Platteneinschübe verzichtet, sollte mATX in jedem Fall passen (hauptsächlich wegen der SATA-Buchsen und dem ATX Stromstecker): https://www.computerbase.de/forum/threads/19-intertech-4088-umbau-auf-15-bay-hdd-backupsystem.1956110/page-3#post-24444876 Dann würde sogar Full ATX passen. EDIT: Ich habe ihn mal gefragt.

Was heißt das? Siehst du im Dashboard, dass jede Disk vom Array Fehler hat oder wie darf man sich das mit dem Read Only vorstellen?

Ein Scrub sollte eigentlich nur lesen. Wenn er schreibt, dann weil was das RAID inkonsistent ist. Die Frage ist ob er schreibt oder die CPU nicht nachkommt. Und was steht drin?

Auf den hab ich auch geboten ^^ War ein Irrtum meinerseits. Das ist ja bereits ein mATX auf dem Foto. Also wenn man das genauso umbauen würde, würde das passen.