BRiT

As typical, @Squid is correct. No good reason to duplicate a well supported plugin.

What else would you be doing over the holidays? 🍬 🦃 🕯️ 🕎 🎅 🎆

I believe there is already a separate rclone plugin.

The 6.8-RC notes states they upgraded to FUSE-3, so maybe rclone needs to be recompiled for this new target?

Was your system performance changed much through changes in these tunables on the older versions? My system performance wasn't drastically changed on older versions, just minor improvements so I suppose I'll be alright. But seeing how vastly different other systems are I would think the new unraid would require some sort of knobs to tune.

So this is something to report to Limetech and they will have to make the changes required in order to get solid performance on wider variety of hardware?

Looks like the 6.8 series will present a new set of challenges on tuning... In particular:

Report issues like that to the Plex Development team, sounds like it's core Plex issue, not docker container issue.

It's just you.

Does swapping cables from Disk 1 and Disk 8 impact the speed test on the valid disk 8 any?

Have you tried turning unraid off and on again, a full reboot?

To put things into a more realistic perspective ... If people have physical access to my server, I'm more concerned about being kidnapped, shot, or killed than my data drives being taken.

I forgot about it being a new month, and having a new automatic parity check. The first tweak was fairly close performance wise to the last regularly scheduled run, but better than the earlier normal scheduled runs. The last tweak using the latest version with a long run has shaved a little over 3 minutes off! Last Tweak: 15 hr, 10 min, 52 secs @ 146.4 MB/s. First Tweak: 15 hr, 14 min, 7 sec @ 145.9 MB/s Most Recent Historicals (before tweaking): 15 hr, 14 min, 53 sec @ 145.8 MB/s 15 hr, 20 min, 12 sec @ 144.9 MB/s 15 hr, 21 min, 5 sec @ 144.8 MB/s 15 hr, 17 min, 56 sec @ 145.3 MB/s

Sorry if I don't agree with your explanation/example using Docker but it's because You can't fix Stupid. If people are going to do Stupid things, they'll always find a way. The same Stupid will have the LUKS password/phrase written down on a Sticky Note by the Keyboard. They probably have it backed up to the cloud in a publicly readable container too.

It does look like it's in an 8x Slot. Well your system does seem a bit of a mystery as to why your Parity Check speeds are limited, unless it's truly limited by the speed of the smaller capacity drives. So the thought was no harm trying to switch to the other slot and see if it impact benchmarks at all. If it's put into a lesser capable slot, then the impacts should be shown immediately, but there's a slight chance it might be put into a more capable slot or at least one that might behave differently. It's more of a this doesn't make much sense, so try something idea.

If it isn't an issue, any chance you can switch PCIExpress ports for the controller? Just to rule out any inaccuracies in the motherboard manual on which port is wired to which?

Replace your slowest drives?

I only received the final notification when using Block. It sounds like its perhaps temperamental on your system?

All my drives are shingled (8TB Seagates) yet I'm in the 182 MB/s range. Your bottleneck is something else.

For completeness, I ran a Long test with 4.1 Beta 2. LongSyncTestReport_2019_08_12_1735.txt

Result from run with dockers turned off. The test results has better consistency. --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 152 | 6912 | 3456 | 128 | 3392 | 181.7 The Fastest settings tested give a peak speed of 182.2 MB/s md_sync_window: 9216 md_num_stripes: 18432 md_sync_thresh: 9215 nr_requests: 128 This will consume 406 MB (254 MB more than your current utilization of 152 MB) The Thriftiest settings (95% of Fastest) give a peak speed of 179.4 MB/s md_sync_window: 192 md_num_stripes: 384 md_sync_thresh: 184 nr_requests: 128 This will consume 8 MB (144 MB less than your current utilization of 152 MB) The Recommended settings (99% of Fastest) give a peak speed of 180.8 MB/s md_sync_window: 256 md_num_stripes: 512 md_sync_thresh: 248 nr_requests: 128 This will consume 11 MB (141 MB less than your current utilization of 152 MB) NOTE: Adding additional drives will increase memory consumption. In Unraid, go to Settings > Disk Settings to set your chosen parameter values. Completed: 17 Hrs 44 Min 58 Sec. LongSyncTestReport_2019_08_10_2343.txt

Was it set to that when you started it up for the very first time? With some docker containers, the devs have it setup so the user/group only happens on the very initial setup. I run LSIO's container and their default template seemed to use UID 2 and GID 2 which maps to daemon/daemon.

I think ... You need to set proper UID and GID on the Emby container when setting up the Docker for the first time so it doesn't use daemon / daemon and instead uses nobody / users.

Yeah, I made sure cachedirs was disabled but forgot to disable Emby that does some hourly scans of the libraries. So it's likely the result of that. I had no downloads or uploads going on with no VMs running and no other server activity. As to using low numbers, I try not to if only because of memories from issues way back in the 4.x days with reads or writes being starved out, and I have oodles of memory to spare where 150 meg isn't a concern. Even though I know everything is setup differently now and those issues shouldn't ever happen with the new software design. For curiosity sake I started a full parity check before the last post to see how it plays out over the long haul. When the parity check finishes and when I can turn off Emby and all dockers, I'll run another Tuner script round trying for more consistency.

Here's the logs from my run. I opted to adjust my settings based on these settings from Pass 2 instead of any of the resulting findings. --- TEST PASS 2 (10 Hrs - 49 Sample Points @ 10min Duration) --- Tst | RAM | stri | win | req | thresh | MB/s 31 | 152 | 6912 | 3456 | 128 | 3392 | 181.7 --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 180 | 8192 | 3686 | 128 | 1843 | 177.7 --- BASELINE TEST OF UNRAID DEFAULT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 28 | 1280 | 384 | 128 | 192 | 177.5 The results below do NOT include the Baseline test of current values. The Fastest settings tested give a peak speed of 181.8 MB/s md_sync_window: 4544 md_num_stripes: 9088 md_sync_thresh: 4488 nr_requests: 128 This will consume 200 MB (20 MB more than your current utilization of 180 MB) The Thriftiest settings (95% of Fastest) give a peak speed of 173.6 MB/s md_sync_window: 384 md_num_stripes: 768 md_sync_thresh: 192 nr_requests: 128 This will consume 16 MB (164 MB less than your current utilization of 180 MB) The Recommended settings (99% of Fastest) give a peak speed of 180.3 MB/s md_sync_window: 768 md_num_stripes: 1536 md_sync_thresh: 760 nr_requests: 128 This will consume 33 MB (147 MB less than your current utilization of 180 MB) LongSyncTestReport_2019_08_09_1119.txt