Unraid OS version 6.9.0-beta22 available

It never does 2 moves at the same time.  As already explained, it's simply the write-caching of the system as a whole.  But, the reason for the delay is that when it also has to switch between drives, then read operations also take effect (to gather directory information, etc).  At this point, the system also switches from reconstruct write down to read/modify/write mode (by design) and that impacts your speeds.  It takes a bit for it to switch back to reconstruct write mode, and depending upon file sizes, how much gets cached to ram, speed of the drives and how often the system actually has to switch from drive to drive, you may see a huge impact in transfer speeds.

 

As your screenshot shows,  the system is currently in read/modify/write mode. 

6 hours ago, Squid said:

It never does 2 moves at the same time.  As already explained, it's simply the write-caching of the system as a whole.  But, the reason for the delay is that when it also has to switch between drives, then read operations also take effect (to gather directory information, etc).  At this point, the system also switches from reconstruct write down to read/modify/write mode (by design) and that impacts your speeds.  It takes a bit for it to switch back to reconstruct write mode, and depending upon file sizes, how much gets cached to ram, speed of the drives and how often the system actually has to switch from drive to drive, you may see a huge impact in transfer speeds.

 

As your screenshot shows,  the system is currently in read/modify/write mode. 

Is there a document or something that talks about things like this? Until yesterday I had no idea Unraid can switch between reconstruct write and read/modify/write mode without me explicitly telling it to. Do you know if there are other settings that can turn on/off when the system deems it required? Anyways would be nice to know of anything else so I can remember it if I'm ever trying to debug an issue.

6 hours ago, trurl said:

When using Fill-up allocation, or even just when you have disks that are very full, it is especially important to understand the Minimum Free setting.

 

Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has more than Minimum, the disk can be chosen, even if the file won't fit.

 

You should set Minimum Free to larger than the largest file you expect to write to the share.

I've tried setting it to a min I feel comfortable with but do you happen to know what happens if it does try to write and it can't fit it? Does it retry or something or can it be catastrophic?

20 minutes ago, Jerky_san said:

I've tried setting it to a min I feel comfortable with but do you happen to know what happens if it does try to write and it can't fit it? Does it retry or something or can it be catastrophic?

The write will fail.  Up to the client to decide what to do with any partial file left over and retry.

1 hour ago, Jerky_san said:

Is there a document or something that talks about things like this? Until yesterday I had no idea Unraid can switch between reconstruct write and read/modify/write mode without me explicitly telling it to.

From the 6.8 announcement

Quote

Reads on devices which are not being written should run at full speed.  In addition, if you have set the md_write_method tunable to "reconstruct write", then while writing, if any read streams are detected, the write method is switched to "read/modifywrite".

 

5 minutes ago, Squid said:

From the 6.8 announcement

 

Interesting thank you

On 6/24/2020 at 12:41 PM, Koenig said:

I got the dreadful error code 43 after updating to this beta and applying this...

What to do now, it was sort of my work@home-production machine with some software from work installed, Autocad, Magicad and some other stuff.

 

Is there a way to get rid of the error 43? ( have dumped BIOS ) and I have the part of the .xml where you specify vendor ID, the graphics card in question is a RTX 2070, pretty please?

 

My guess would be that something in those arguments tipped the driver off...

 

EDIT: Yes pretty sure something in there breaks Nvidia passthrough, tried it on my other VM with a GT 1030 passed through with the exact same result, error code 43....

 

EDIT2: Attaching my diagnostics if it could help someone to solve this.

unraid-diagnostics-20200624-2210.zip 114.66 kB · 4 downloads

If this is still an issue in latest beta, please open a separate prerelease bug report.

On 7/3/2020 at 3:19 PM, testdasi said:

@limetech is there any way to repeatably trigger the unexpected GSO error for testing purposes?

 

I found running <model type='virtio'/> + machine='pc-q35-5.0' also stop the errors for VM use without the performance penalty of virtio-net.

I have been dumping a few TB of data from VM to a share in my backup job so I reckon I should receive plenty of errors by now but I haven't. Hence, wondering if there's anyway to trigger the error manually just to be sure that it's not coincidental.

Hello, I am having a similar issue. Did you figure it out? Is that a good workaround?

 

Edit: after trying your solution, it increased my transfer speed (over SMB) from my VM to a Share located in the SSD from ~100MB/s to ~250MB/s. So that is good, but the SSD should still be able to read/write at higher speeds, maybe it is limited by the SMB overhead. It is a SATA MX500 so it should go up to ~500MB/s.