JorgeB

Just one more thing, what I wrote above assumes the device uses a supported filesystem and was formatted with UD in the last couple of years or so, if it's was not formatted with UD (or with a very old UD version) most likely it will not be mountable by Unraid, still nothing will be deleted as long as it's not reformatted by the user.

This.

You'll need to reassign the cache devices.

Some differences are always normal due to shfs overhead, but dd isn't a good way to test this, it will result in inaccurate results, do a regular SMB transfer instead.

You can easily revert back to the previous release, manually or using the GUI (if the update was done using the GUI):

Yes, any change on the shares page will restart Samba.

You just need to create a new pool, assign the device and update the local paths, note that you'll need to create a new top level folder to be the share, e.g., if you had it as: /mnt/disks/downloads it would be shared by UD on SMB as "downloads", now if you create a new pool e.g.: /mnt/mynewpool and need to create a new top level folder called "downloads" and move everything inside that folder, local maps need to be corrected, from "/mnt/disks/downloads" to "/mnt/mynewpool/downloads" anything/anyone accessing the share with SMB can use the original mapping (//tower/downloads)

You should do this.

Why do you have Samba restarting several times, e.g.: Jun 18 09:00:19 Dumbo emhttpd: shcmd (5372): /etc/rc.d/rc.samba restart A Samba restart will interrupt any current SMB transfer(s).

Please post diags after both a restart and a cold start.

Just to add that I did nothing else other than booting with the different betas, and if I go back to the old beta writes again increase massively, here are a couple of 30 second videos showing the real-time write difference: b1.flv b22.flv

If the BIOS doesn't see the disks they will never show up on Unraid, test the disks on another PC if available.

Do a new config, then you can re-sync parity.

No need to worry about those, they are normal.

Or it wasn't btrfs in the first place.

No btrfs filesystem is being detected on the SSD, perhaps it was wiped?

Most likely the wrong cables, but difficult to say for sure since the page doesn't have a detailed description or part number.

Well, that's disappointing, but basically the information I had was from someone using the latest betas saying that the writes to the docker image for him had decreased by multiple times, so I wrongly assumed the issue was fixed by LT, possibly just a result of other changes, still I can confirm that at least on my test server the information I got was correct: Writes to the same docker image after 5 minutes, v6.9-beta1 vs v6.9-beta22, also note no increase on btrfs-transacti: Now idea if there will be a difference to everyone, please try and post here.

You should try v6.9 -beta as there are some known issues with the Ryzen SATA controller and older kernels. That's fine, up to 2 x 2933 is OK (depending on board)

IIRC the H310 mini can now be flashed to IT mode, you should find how if you google it.

SFF-8087 to SATA reverse breakout cables - if connecting the backplane to regular SATA ports on the board/controller SFF-8087 to SFF-8087 to connect the backplane to an LSI or similar controller with miniSAS ports.

That one is also reverse breakout, they have the Supermicro model# on the page(Model-nr.: CBL-0294L-01): https://store.supermicro.com/supermicro-internal-reverse-breakout-crossover-minisas-to-4-sata-70-70-70-70cm-cable-cbl-0294l-01.html

To use rsync you'd need to stop the VMs first, docker should still be OK, since you don't need the docker image, only appdata, or use the CA appdate backup plugin witch automatically stops then restarts them, alternatively and for everything you can use snapshots.

Please try again a regular SMB transfer and post new diags after it errors out.

Also make sure the cables are forward breakout, reverse breakout look the same but won't work in this case.