Marshalleq

Thanks everyone for this fine thread. I've been considering doing this for a while due to the series of unfortunate events below and hadn't clicked it was so easy. My two issues were: 1: If any automation or VM's etc decided to run, Plex couldn't transcode to disk fast enough in order to keep up with real time video (on a single stream even) and thus, a media item would 'pause' in the middle while watching it. So, an I/O issue. 2. I had two SSD disks die (an Enterprise Samsung SM863 960GB (new, died in under a year and Samsung's not covering it due to being OEM) and an Intel SSD330 60GB). The latter is obviously older, but being MLC based figured it would be fine as a transcode device, but no. Lessons learned: 1 - Even though SSD's are rated for something, I don't really want to have to keep buying them at their current prices, so I should make their lives easy if I can. 2 - By using /tmp it reduces I/O on the PCI bus which helps other activities 3 - Don't buy OEM drives unless you're 100% sure the warranty will match the original manufacturers warranty 4 - At the moment buy Intel SSD's - The price for an Intel branded enterprise 1TB drive rated at 1 drive write per day for 5 years (the warranty is 5 years) is about the same as a Samsung good 1TB consumer drive which doesn't have the IOPS or endurance. I paid about $300 for it in NZ dollars (compared to thousands for other brand Enterprise SSD's like the one that died above). It's not the fastest drive, but you don't need that, you need reliability and IOPS in the server space. And as it is, the Intel still does 95,000 IOPS READ / 36,000 IOPS writes. If you think the write IOPS are low have a look at HDD's - a new Seagate Barracuda 12TB HDD does about 215 IOPS. So who's going to complain about 36,000? Not me.

Oh yeah, I should probably update that! Thanks

Thanks, sorted that and yes it's much cleaner now. I did run your script once previously but somehow did overwrite it with the wrong one lol. Thanks again, I'll do some more testing again later, when there's no-one on my server to skew the results!

Hmm, that's interesting, OK I'll have another look at the script, I must have gotten the old one mixed up with the new one somehow.

In the interim I seem to have gotten around the problem by running ln -s /usr/local/sbin/mdcmd /root/mdcmd, which is what I had to do on the old script too if I recall correctly.

Anything is possible, but it's not designed for that. It's designed to run manually so you can run it and rerun it to get the optimum settings for disk performance on your particular setup.

@Xaero there still seems to be quite a major issue on my hardware - see below results: Completed: 0 Hrs 56 Min 11 Sec. Press ENTER To Continue unraid-tunables-tester.sh: line 55: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 598: [: : integer expression expected Best Bang for the Buck: Test 0 with a speed of 1 MB/s Tunable (md_num_stripes): 0 Tunable (md_write_limit): 0 Tunable (md_sync_window): 0 These settings will consume 0MB of RAM on your hardware. Unthrottled values for your server came from Test 0 with a speed of MB/s Tunable (md_num_stripes): 0 Tunable (md_write_limit): 0 Tunable (md_sync_window): 0 These settings will consume 0MB of RAM on your hardware. This is -299MB less than your current utilization of 299MB. NOTE: Adding additional drives will increase memory consumption. In unRAID, go to Settings > Disk Settings to set your chosen parameter values. Full Test Results have been written to the file TunablesReport.txt. Show TunablesReport.txt now? (Y to show): I was expecting more for 56 minutes of testing It doesn't look to me like it's autodetecting mdcmd which I think you said it would earlier....

Just to copy it to /boot and run it basically.

Hey, I'm in the middle of running this while I cook dinner - thought I'd share the output incase you can shed some light / adjust the script. Sorry to see you've been sick BTW, hopefully on the mend! unRAID Tunables Tester v2.2 by Pauven unraid-tunables-tester.sh: line 80: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 388: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 389: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 390: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 394: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 397: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 400: [: : integer expression expected Test 1 - md_sync_window=384 - Test Range Entered - Time Remaining: 1s unraid-tunables-tester.sh: line 425: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 429: /root/mdcmd: No such file or directory Test 1 - md_sync_window=384 - Completed in 240.717 seconds = 0.0 MB/s unraid-tunables-tester.sh: line 388: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 389: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 390: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 394: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 397: /root/mdcmd: No such file or directory unraid-tunables-tester.sh: line 400: [: : integer expression expected Test 2 - md_sync_window=512 - Test Range Entered - Time Remaining: 1s unraid-tunables-tester.sh: line 425: /root/mdcmd: No such file or directory It repeats from here.

Thanks, downloaded that and it's running now, about to give it a go!

I actually hadn't edited it. I use VI and Nano so I don't think there's much chance of it coming from my end? - are you saying it was published to this site with windows line endings and I need to change it? In which case I probably would need to do that with something (I run Mac) but this would be a first in 20 years!

@XaeroDo you have something installed that we need to add? I'm getting command not found error, bad interpreter errors and file not found errors.

Wow, can't wait to try it out! Thanks for your help on this!

No I didn't, it's bloody awful isn't it. I'm really not sure why it's happening either. Did you happen to be experimenting both with passthrough PCI device via stubbing the drive and also via the XML code in the VM? I seem to remember it started when I did one of those but not the other, though removing either / both didn't fix the issue.

Actually, I was surprised Unraid did not have this time tested feature. I personally think a hot spare capability would still be of benefit in unraid. Even though you only lose one disk of data in unraid, it is actually also about the risk factor of losing another disk. Once one disk is gone, you can rebuild that, but a second no. Liklihood of more than one disk dying simultaneously? Well, more likely the more disks you have. And yes it does happen. One advantage of a hot spare particularly for smaller builds is that you could do away with the negative performance impact of dual parity and still have cover to reduce the risk of a second disk dying, which is heightened once one disk has died, e.g. due to the extra heat from having to constantly calculate the parity of the failed disk. It's a really great feature and unraid is the first redundant system I've ever seen that doesn't have it.

APFS is a containerised file system. I think you mean SMB. Apple still operates AFP, however it is clear it is moving to SMB. It still works and I imagine it will for some time, but new features and development will likely be across SMB. Yes, that's the Windows networking protocol being used by apple.

I came here because I'm experiencing similar. The unbalance app seems to be much, much slower than it should be. I have come to the conclusion there is something wrong with it, or some ballooning error that happens with long transfers. When it eventually finishes it's large file copy to (shifting between enterprise disks which is currently scheduled to take 14 hours for the remaining 1.6TB, I will do it by command line. I've done all sorts of large copy operations on the system and only since using unbalance has it been slow. Also for @rclifton I note that the unbalance plugin, does not equal the same as the actual transferring speed of the drive as reported by unraid. Clearly the speed field in unbalance is taking all sorts of things into account and averaging it out. But, this being my first time doing whole drive cleanup with the unbalance plugin, I note it slowed way down after a couple of hours. Originally based on it's then active transfer speed, it was going to take 5 hours for a 3TB copy, however it's now been running for 20 hours and it's done 1.4TB only. Some observations that seem odd to me include at times the disk is reading and writing from the same disk at the same speed in both read and write columns of 75MB/s and simultaneously the drive it's copying from is only running at 10 or 20MB/s sometimes less. Other behaviour that seems odd to me, is it cycles between reading from the source drive (and not writing to the target), then not reading from the source drive and writing to the target. So it's like copying it to a buffer somewhere. Something I'm sure is not normal for a normal move or copy operation. That all said, I accept I don't know lots about how Unraid operates and perphaps I don't understand something. But it in no way feels normal. I did have some custom disk tuning set up which gave me larger write speeds. I've reset that to defaults, but it hasn't helped. obi-wan-diagnostics-20190705-2317.zip

Well, one would think that Unraid's / linux's mounting of the exfat system would be enough to tell the OS to ignore file permissions. However when you're running a tool that is explicitly trying to change permissions on a target file system that simply does not support ANY permissions, it's hard to blame Unraid. I'm not sure, but it's possible there's an extra mount flag that isn't being run that would get around this issue - which would have to be a feature / bug request with unraid. Perhaps you could try that.

Awesome, I have to admit, I do love how flexible rsync is - definitely check those errors though, there shouldn't really be any. Good luck!

Well, exFAT as far as I know doesn't support permissions. My first guess (and some small memory of having done similar years ago) is this is part of why. Though in that case the files did copy and the error was informational. I can't tell with your rsync logs, but certainly MC doesn't seem to be informational. rsync does have an option to skip permissions. I think it's --no-owner --no-group and / or --no-permissions. Or using archive (a) with rsync, maybe don't use that as that explicitly copies permissions. I can confirm it doesn't happy on my UD drives, though all of those are either XFS or BTRFS. Edit: If it really becomes a problem, you could just copy to the network share within unraid. Internal unraid network copies are 10Gb so not too bad. The share would get around the permissions problem I think.

Does anyone know if there is a way to get disk io from the attached unassigned devices? I'd really like to be able to visually see real time so I can guage the amount of writing to my attached SSD's. Thanks.

I can't remember what it's called now, but there is a way of displaying free memory that doesn't really show you the free memory. i.e it shows up as used, when actually it's cached or something, but still available to use when needed. So possibly depends on what you used to show the free / used memory? Unraid GUI or something else? Also, depending on how you assigned the memory to the VM, it's either dedicated or ballooned. If you assigned the 10G in both fields of your vm config, I believe that's dedicated, what it sounds like you want to do is have shareable memory (like most other vm servers do by default), which means you need to put in a range. Also, you need to ensure the balloon driver is installed in the guest. Hope that helps.

What kind of link would prove to you that it was OK? I'd take a guess at only a court case? I could do a google and try and find it again, the problem is no-body seems to want to test the theory - legal theory or not. What changes it from theory? Only a court case I expect. And nobody wants to go there, unless we find google adopts it or something I'd say fat chance.

LOL, no, I came to unraid for a reason. And I am so sick of hearing people argue over at FreeNAS about ECC ram. The Unraid raid driver is built by lime tech and to that end if an option can be dreamed up, I'd agree with going that route. Ultimately yes, self healing is what I am salivating over, along with the whole shebang of ZFS - like many others. However, most linux systems include support for all the filesystems and there are pieces of each that can be useful in different scenarios. So on one hand yes, it would be great to build in some self healing into unraid, but there is all sorts of other stuff ZFS has too. Who knows maybe there's something in the code that could be brought in. Also I don't think we can say it's not RAID when you think about what RAID stands for. RAID HAS typically been striped or mirrored data, but nothing says it has to be. Primarily lime tech just got rid of the striping and figured out that meant you didn't have to have the same size disks. Netgear also figured this out (very similar) with their X-RAID implementation on ReadyNAS, and I know there's at least one other out there.

I think the Licencing concerns do exist, but as concerns not as facts. Pretty sure that's been proven illegitimate now, of course that the concern still exists in peoples minds is enough to be a problem.