RobJ

I've been reading up on write caching, and the various settings that affect it, and it's a complex topic! There are 2 schools of thought, go larger and go smaller, and the prevalent one seems to be to go smaller. The current settings were set up when memory sizes were smaller, 512MB or less, so the ratios are already allowing much larger memory amounts for write caching. That initially seems like a good idea and why some feel you might as well make them even larger, but there's a problem. At some point when it maxes out the allotted space or expires (30 seconds I believe), the system *has* to flush that data out, and it takes MUCH longer to flush say 20GB than 20MB, causing enormous latencies because the flushing becomes the highest priority. That's why many feel it's better to go smaller and force constant small writes, creating consistent streaming, both in the general writing and for consistent execution of other processes. Some suggest using the byte forms instead of the ratio forms, for tighter control of write cache space. E.g. vm.dirty_bytes and vm.dirty_background_bytes instead of vm.dirty_ratio and vm.dirty_background_ratio If all you do is handle small files, then going huge is not as much of a problem. But usually there comes a time when you want to transfer 100GB or more, something more than your write caching amount. At that point, it's my understanding that the kernel says "whoa" to everything else, and concentrates on draining the write cache, resulting in a nearly unusable keyboard and mouse, unresponsive programs, broken media streams, etc. This is all 'book larnin', what I got from Googling. You guys have the real world experience. What do you think? Have you tested the various scenarios (high and low ratios, with high and low write amounts, with simultaneous streaming, etc)? Some relevant reading - * Better Linux Disk Caching - a fairly balanced intro to the controlling factors and settings * The pernicious USB-stick stall problem * http://unix.stackexchange.com/questions/107703/why-is-my-pc-freezing-while-im-copying-a-file-to-a-pendrive?lq=1 * http://wiki.archlinux.org/index.php/sysctl#Virtual_memory - and "Small periodic system freezes" farther down * Toward less-annoying background writeback - an interesting article about future plans for smarter write caching, self-tuning; shows how complex this problem is In addition, the USB articles above may have a fix for the system problems some have had with USB "high speed resets". More reading - * Linux hang on USB writes * Change value of USB "max_sectors" If someone with experience in udev rule making in unRAID can create a procedure from this, that would be another good tip for the page.

This thread is for feedback for a new Tips and Tweaks page on the wiki. Feedback includes ideas, suggestions, criticism, questions, requests, discussion... It's my first stab at collecting a bunch of tips, tricks, and tweaks for unRAID, to help make it work right, fix known issues, and make it work better, safer, and possibly faster. I started by wanting a single place for users to find ideas and fixes for the current bugs with recent 6.1 and 6.2 releases. Obviously, it needs to be dynamic, and change as often as necessary. I've started with a small collection, not really knowing which are good and useful, which are suspect, which are bogus, and which need correction. But I'm hoping the great collection of helpers here will refine it, either directly by editing the wiki page or indirectly by suggesting the changes here in this thread. I hope that some will be removed in time, as they are incorporated into new unRAID releases. Hopefully, this may also help LimeTech, as they monitor what works and what doesn't work. When we point users with relevant issues to the page, we should request their feedback, as to what helped and what didn't. After a short review period, I will post about it in the latest beta announcement thread.

There's practically no chance this is a bug in unRAID. The fact that changing to DHCP seems to fix the network makes it pretty clear there was a wrong network setting. Using DHCP doesn't just give you a correct IP, it also gives you a correct gateway, mask, and DNS server settings. Unfortunately, none of the posters above shared their network settings, but I have to assume that each one had something set wrong. Often the best way to get good static network settings is to start with DHCP, make a note of what it gives you (IP, mask, gateway, and DNS servers), then adjust the IP if desired (within the valid range for the provided IP), and change to a static IP with those settings.

From what I've seen, the average parity check time for the average unRAID user is roughly 3 times the size of the parity drive, about 3 hours per terabyte. That's based on average equipment and mixed drives, both in size and age. That means about 12 hour parity checks for a 4TB parity drive. Some users do get better than that, with all high performance drives on high performance controllers on high performance busses. Users that talk about their parity check speeds often have higher performing hardware. The average user however is likely to be reusing older hardware and drives, trying to extend their life (at least in the past before VM's). If a user is getting less than 3 hours per terabyte, then there may be a problem with their hardware, or they are using somewhat lower performing hardware, such as very old drives, IDE busses, the PCI bus, etc. My apologies to you speed merchants, but I didn't want average users feeling bad about their systems.

Thank you for that! I've updated the page as suggested. I should have thought of it myself!

Another item to check, if you are interested, is the ps report, checking for processes that are monopolizing the CPU. I admit I don't have a lot of Linux experience, but it's hard for me to believe that any process should ever be using more than 90% of the CPU. I cringe when I see users reporting that something is using 100% CPU. Things don't work right if that's true. Interrupts won't be handled in a timely way, and that causes spurious timeouts and freezes in devices and processes that are otherwise completely fine, except they are starved for CPU attention. Helpers can then be mislead by these timeouts and subsequent errors, when all that device or process needed was some CPU love. The real problem is the runaway process hogging the CPU. A potential future fix would be to display the offending process, and request permission to kill it.

Here's a big one *if* you are interested. A number of users with problems appear to have a full /var/log, causing additional problems for them. You are checking and reporting if it's filling up, but it would be really great if you could *truncate* the huge space wasters, and instantly give them some more space and time. It could possibly enable diagnostics collection, and powerdown, and any other safe procedures they might want to run, perhaps to diagnose further what's wrong. This is of course an action, a fix, not just a detection and report. We discussed this around here, and you questioned the loss of logging info after truncation, a valid quibble. I don't know if you still feel the same, but I still feel that data past the first 500KB is totally useless, not even worth saving, unless someone can come up with a valid reason why it might be useful. jonathanm's subsequent remark was apropos, although I'd rather not save the truncated garbage. Burn it! I do still think it could be a big help, allow them to continue a bit longer, long enough to grab full diagnostics. And the very fact it worked (if it does!) allows helpers to narrow the real problem down sooner. I'd loop through the files there, and truncate any that are larger than 5MB down to 2MB. Those are my suggested numbers, change as you like.

Would it be a bit more intuitive if you reversed it, changing "Ignored Sensors List" to "Usable Sensors List" or "Valid Sensors List" or "Sensors List (unchecked will be ignored)"?

I've added verbiage and pointers to 'Fix Common Problems' to Need help? Read me first!, Troubleshooting, and How-To's, and you've added it to the forum FAQ. Can you or anyone else think of any where else it should go?

I would be believing what the kernel is telling you until you have more substantial evidence that that assumption is wrong! What I suspect is happening is that you have a problem with the bonding of the CPU cooler to the CPU chip. Perhaps it is old/misapplied heat sink compound or a loose heat sink. You should also check that CPU cooling fan is running. I strongly agree with Frank, you need to assume it's too hot, until you prove otherwise. Two ways, reach in and touch metal close to the CPU and see if you burn your hand(!), or reboot and check what the BIOS says. Did a little searching, and those numbers look suspect. Apparently auxtin and PECI Agent are often miss-configured or possibly even miss-wired, and MB Temp and CPU Temp are probably arbitrarily assigned by you (in sensors.conf), not necessarily correct. It's possible that PECI Agent is swapped with CPU Temp, not sure what auxtin is.

Just ran the new version, looks great! My personal opinion, I think that the auto-update for this plugin (Fix Common Problems) should be a Warning not an Error, but it's not a big deal.

Yeah, I'd be leery too. There's no way I'd do it in less than a multi-step process - double check the destination is valid and has space, copy the files, verify the copies are perfect, then and then only delete the originals. And I'd probably tell the user to try it first with test files, to make sure it's configured and working right.

What I'll do is switch it over to being a warning, as its not exactly a major error, and the system is still functional with it like that. Thought even more about it, and what I'm going to do is completely remove the options to have this plugin move the data around for you to/from the cache, and instead point them to dolphin / krusader / mc. I'll just leave the suggestion to fix the settings however. Makes my job a ton easier, and takes me off the hook if anything unexpected should happen during the move. Ahhhh ... You just tossed the holy grail back in the cave! Here I thought we were on a course to a tool that could find all problems, then fix them too! Like the Elysium movie medical machine.

Just checking one thing, the messages above are for sdc1, is that hard coded? The drive symbols can change between boots, even more likely after OS updates. It's always best to refer to the drive by something more permanent than its drive symbol. But ignore me if I'm off-base!

I responded privately, but I'm not sure that others recognized the significance of Squid's idea here. Those of you who take the time to help others will appreciate how useful this could be, and probably have additional ideas of things to check for. Here's a few that I suggested, listed again just to spark some more of your ideas - Some aren't actually fixes, more like recommendations, don't know if you want to go there, perhaps a separate section. And I know Squid was going first for app and share related fixes, but why stop there? This could be the start of a great and comprehensive diagnostic tool.

According to the numbers, it's not old, it's not even middle-aged, it's young. Media_Wearout_Indicator is the lowest at 88, down from 100, which is like saying it's 12 now and expecting to live until it's 100. That's of course very optimistic, but it's what the numbers say. I'd look for others with the identical drive, and see at what point it failed for them.

The drive itself says it's fine, don't have any evidence to doubt it. It does have 30000 hours on it, but the numbers imply a lot more life left.

Some controllers don't pass SMART data back, or require special parameters to do it. Can you get a SMART report from *any* drive on that controller, using any method?

Howdy, health issues have limited me lately, but just want to say - no problem. You presented valid uses, and very valid points! Certain 'gray areas' have become entrenched here, and changes if any would have to come from the top, not me.

I'd try and rework it so that it stands alone without involving the other thread Agreed, I would prefer a complete answer, standalone and as general as possible, in either FAQ. However, I realize my answer is somewhat hypocritical, as I've been the worst offender, in placing a Q in the FAQ with only a link to the answer somewhere in the forums. I didn't have the time or the inclination to rewrite someone else's answer in the FAQ. As to the place you put it or who does it - I really hope you will control that yourself. One of the huge problems with the past wiki work is that only one person was behind most of it, and that tends to inhibit others who could have participated, contributed. I was happy to do it, but it wasn't a good way to proceed. I therefore think it's extremely important for the future of the wiki (and similar community managed works) that as many authors as possible get involved. There will be some inconsistencies and small conflicts when you have lots of cooks in the kitchen, but so what! A small personal comment - I've been battling A-fib and flutter for quite awhile, severely impacting my availability here, can't think well during the frequent episodes. A week ago, I had a cardiac ablation and am hoping for improvement, but major anesthesia has whacked me down, little mental energy and only in small bits and dabs. Today seems better, but we'll see. I had so many things I wanted to contribute here, but no mental energy to work them out. I'll help as I can.

I gave it some thought, and felt it was better unified, so I did, inplace in yours. But I can see a rationale for a separate posting dedicated to just appdata pathing. However, I also realized you had found a great way to transfer control of a posting to another user(!), with the help of a moderator, to a user who may be better suited for ongoing maintenance of the subject matter. And you are closer to that subject matter than I am. So I've modified your post to unify it, deleted mine, and pointed the Q's in the index to yours. Feel free to rewrite/reformat/fix it as you like.

Just a friendly reminder - according to the Forum Rules, especially #5, no illegal or hurtful activity is allowed here, and I believe that would include the facilitation of activities that could be hurtful to persons or entities by hash-cracking others passwords. Please be very careful here.

Agree but I don't think I'm the right person to write it, haven't experienced it that way. I'm hoping you can?!? I actually experienced something like it, some time before the current crop of Chrome reports. While using Firefox, I could not get a slot count change to stick, finally discovered it would only stick when I used Chrome. I then repeated that over and over again, it would fail in Firefox, work in Chrome. When I reported it, bonienl could not repeat it though, it worked for him everywhere.

Reserved

WARNING: There is now a dedicated site for Unraid documentation here that should be considered the definitive documentation. As a result links in many forum threads (including this one) may be outdated as they point to the old wiki version of the documentation. This is the feedback thread for the forum FAQ, as we don't want anyone cluttering the FAQ up. Anything that's added to the FAQ that's not a Q with A will be moved to this thread. This is the place for suggestions, complaints, requests for FAQ entries, and any discussion about current FAQ entries. I've started this FAQ for unRAID, to be general in nature, for any one of our community helpers to add Frequently Asked Questions. It is Squid's idea, and a good one, based on the existing Docker FAQ and its Docker FAQ Feedback thread. I've also started updating the wiki FAQ for v6. I spent quite a few hours today on it, thought I'd accomplished a lot, then measured how much and found it was only about 20% done! So there's still a lot to do there, but it does have a lot of good info on unRAID. I'm working down from the top, with a red warning line marking how far I've got (I keep pushing it down ahead of me). I'd appreciate anyone reviewing my rewrites for accuracy or improvements.