[[6.8.3] docker image huge amount of unnecessary writes on cache]

2 hours ago, johnnie.black said:

 

Still a few months away, at current pace I estimate hitting 1PB around Halloween, this assuming the NVMe device doesn't give up the ghost, since it's well past its 300TBW rating.

Good luck for that, but as your numbers are way higher and the nvme is still working I can sleep a bit better with my 50TBW up till now

As everything else is working great and the only issue is still in the current stable release I might skip 6.8 totaly and wait for 6.9.

So lets hope that 6.9 rc1 is just around the corner and has this one fixed.

I am eager to test that new release out because of the multiple cache pool options, but as I have only one system available I want to wait at least for a RC version before upgrading.

[[6.8.3] docker image huge amount of unnecessary writes on cache]

On 5/14/2020 at 1:59 PM, johnnie.black said:

While we wait for the fix, anyone reached a PB? I'm not that far:

 

Just because I'm curious: Did you hit the PB yet @johnnie.black

[[6.8.3] docker image huge amount of unnecessary writes on cache]

7 minutes ago, grigsby said:

 

The bug was originally reported in 6.7.2. The thread title was change to 6.8.3 when it was discovered that it still exists in the current release.

 

I did not realize that. 
That makes it more likely that its the same issue. 

[[6.8.3] docker image huge amount of unnecessary writes on cache]

Just read this thread today, as I wanted to see if there are any major roadblocks for me when upgrading my system from 6.7.2 to the current stable release.

After reading thrue all ten pages of this thread upgrading to 6.8.x did not seam to be a good idea

 

Now that I am home and have access to my system I checked my cache pool drives on a otherwise well behaving unraid install and found out, that my two Samsung EVO 860 500 GB Sata drives which are only 3 months old have written about 50 TB if the LBA calculator did not lie to me.

 

Reading the thread it looked like a 6.8.x issue allone, but as I am on 6.7.2. and I am pretty sure that I have in no way intentionally written that vast amount of data to those poor little SSDs I might be in the same boat as the rest of the bunch, but can only confirm that it is the same issue after further investigation.

 

With this rate I would chew thrue the 300TBW warranty limit in about 18 months - puh

[[6.7.x] Very slow array concurrent performance]

25 minutes ago, itimpi said:

I did not think the RC was even trying to address this problem?   Instead it is focused on getting to the bottom of why some users are experiencing SQLite DB corruption.   Having said that I guess the two issues could be related in some way

I am reading on both threads for a while now, even if I have not experienced the SQL Bug yet. 

What seems to be common to both issues is that using a cache drive mitigates both issues in some way. 

SQL Lite Bug seems to affect only users that do not have their app data on the cache drive. 

On the other hand caching my media share helped a lot with transferring new content to the server while it is being streamed from. (And make sure that mover only runs at time with no server usage) 

 

I think it is highly likely that those two issues are connected and a solution for one of the issues could may be solve both. 

 

@Marshalleq Please keep us updated on what you find out. 

 

 

 

 

[[6.7.x] Very slow array concurrent performance]

I am running UnRaid 6.7.2

I have seen the same behavior on my box when streaming to one of my clients. Everything runs buttery smooth until I try to copy some new files to the array. If I write directly to the array while streaming the stream freezes. 

I have mitigated the issue by caching my media share for the moment, so loading content does not interfere with streaming from the array (or an unassigned device for that matter). 

But that can not be a viable solution. I normally do not stream when mover operations are running, so I can not say anything about the impact of mover. But streaming and writing from/to the array at the same time was definitely working in earlier Unraid versions and currently it does not.

I have just adjusted my scheduled times for mover and parity checks so I can make sure that they do never run at the same time - just to be save for the moment.