RobJ

With only one NIC, you're unlikely to have network issues, so that's almost certainly not the problem. Don't bother with bonding, no point in bridging either yet, may help later when the system is operational. If you don't already, make sure you have a complete backup of your boot drive, just in case. Then using either this boot drive, or another one, prepare a fresh boot drive with either 6.3.2 or 6.2.4 from the Lime Technology download page. Use the instructions on their Getting Started page. I'd try with 6.3.2 first, if it doesn't boot, then repeat with 6.2.4. Once you can boot with either, before copying your own config to it, type diagnostics at the command prompt, and diagnostics.zip will be saved to the logs folder of your boot drive, where you can access it and post it here. If that worked, then you can make sure your usual boot drive is prepared, and try restoring from your backup your config folder to it, and see if that boots ...

As Squid said, it just started, about the same time you did, and we are all just now getting used to this new forum software. We've never had a reputation feature before. But your giving rep has been much appreciated! Thanks!

Did you go through the networking sections of the Additional Upgrade Advice? There were some significant changes made. And once you can access it over the network, there's a sticky in this board for 'Windows issues' that *might* help.

That sounds about right. That's 5 a minute, about 12 seconds each, for 5 to 10GB files. The bigger the file the longer it takes. Deleting large files in ReiserFS is MUCH slower than deletions in FAT or NTFS, which is what most of us are used to, and spoiled by. After converting to unRAID v6, and if you convert drives to XFS, deletions will somewhat faster.

Well, that's the problem, if it's non-functional you can't boot it. If you can boot it, in any mode, it's functional. However we have seen a few motherboard cases recently where you can boot into the bootGUI mode but not the console mode. So do try it.

The diagnostics you posted only showed the drop of the boot drive, a USB connection. No other drive was dropped. None of the other drives were assigned because there was no super.dat available, so they would have appeared as unassigned drives. We would need to see the errors that occur when Disk 2 is dropped, in order to know what is happening to it. It would not be the same thing as the boot drive dropping, because they are SATA connected, very different from being USB connected. In general, without knowing why Disk 2 was dropped, your steps look correct - unassign Disk 2, start and stop the array, reassign Disk 2, and restart the array to rebuild it.

And we do all really appreciate what PhAzE has done with these plugins. But the future is in Dockers. While of course I can't speak for PhAzE, what I think would be better is an effort to create very simple upgrade paths to Docker replacements. Ideally, with a simple tool that auto-configures it, so that one minute you are running the plugin version, then 5 minutes later you are running the Docker version, and it's fully operational with all of your data and configuration! Nothing lost, looks basically the same, except possibly a newer version of the app. In this case, it might be a small script with a few instructions, that moves you from a PhAzE CouchPotato plugin to a Radarr Docker container. Or more simply, a set of steps as to what config items to note, and where to plug them into the replacement. But I don't intend to be pushy, to either PhAzE or his plugin fans. He's certainly earned the right to do anything he chooses!

No, the Mover can run any time, just like another user on the system. It's just using rsync to make copies and moves. However, it's my current belief that the Trim operation is best performed when nothing else is writing to that drive (although I could be wrong).

Once you lost the initial access to the boot drive, and therefore lost /boot, there was no way to save any reconfiguration or drive assignments. Drive assignments are in super.dat in the config folder of the boot drive. /boot is tied at boot time to a USB device with a FAT file system containing a volume label of UNRAID, in your case /dev/sda. Before the array was started, the drive was dropped, and all assignments lost at that time. It was quickly found again, assigned to /dev/sdh, but not seen any longer at /boot. I *think* the port you used was a USB 3.0 port, and we have seen a number of reports of flaky behavior with those under Linux. Try a USB 2.0 port, that has worked for many. I suspect that the USB 3.0 Linux driver support still needs maturing.

According to your syslog, your Mover is set to run every hour! As you are already reconsidering whether to cache it or not, until this issue is fully resolved, I agree it might be a good idea to not cache the largest files, for now. In both of your cases, I believe it took 3 or more days before the issue came to a head. I suspect therefore you could get away with rebooting every 2 or 3 days, and not see the problem. Obviously, that's an undesirable workaround, but hopefully it's only temporary, until someone spots what needs to change.

As he said, you don't need 6.2.0, you can go straight to the latest, currently 6.3.2. The upgrade to 6.2 (or later) did have some special quirks, some of which you have read about, but the rest I put into the Additional Upgrade Advice, which may help you. In particular, I'm wondering how much RAM you have, because recent upgrades have grown large enough that they may take up too much RAM when unzipped into RAM, the way the plugin update method works. If you have only 1GB, you'll have to upgrade the old manual way, by extracting the bz* files to the boot drive. There's a section in the upgrade notes about that.

I can't point to the studies that corroborate it, but it's long been my understanding that hours spinning is not as hard on the drive as number of times it has to spin up and down. If the drive needs to spin up and down a few times, then it's my understanding that the drive will last longer staying spun up. Minimizing drive hours is not as important as minimizing spin changes. A spinning drive does use more power, and generate a little more heat, but will probably last longer with fewer spin ups and spin downs.

Try unRAIDFindDuplicates.sh, I think it should help. Otherwise, I would use a double pane file manager, like MC or Krusader or Dolphin, to compare folders and delete the duplicated folders and files.

This looks nearly identical to the issues that @al_uk had recently, looks like a huge memory leak. You had run fine without issues for quite a few days, then during a Mover session, with movie files being moved (probably very large ones), java and nginx and php all report "page allocation stalls", of 10 to 12 seconds, that continues and gets longer, then there's an OOM, with the largest java getting killed, which allowed it to continue for about 12.5 minutes without trouble, then it apparently runs out of free memory again, and the stalls are nearly continuous, and keep getting longer, over 30 seconds each. Then the mover finishes, and there's no more trouble. (But I would strongly recommend you reboot after that, which I believe you did.) I don't know for sure, but I *think* the stalls are garbage collection related, which would implicate java. I don't know if you can run without whatever is java-based for a week or 2, but that might end up being what you have to do. al_uk's post, problems and syslog look much like yours My response follows that one. I don't know exactly what the solution is here, but it would be good to hear from al_uk, what is working better for him.

Interesting to see an almost brand new system getting started. I suspect you had previously started, and formatted the 2 data drives with XFS, then re-prepared the boot drive cleanly, and started again. It started with apparently nothing configured, then you began configuring various network and identity items, installed a few basic plugins, then assigned drives, tried an array startup, stopped it, made a few more changes, and started again. But only a minute after installing 4 Dynamix system plugins (Stats, Temp, Info, and Buttons), the php segfault occurred, and shortly after that a number of diverse things went wrong. I suspect the segfault was the first indicator of an unstable system. But I don't see any obvious dependency issues, and you have tested your RAM (the usual suspects for segfaults). Because it happens so close to the installation of those 4 plugins, I'd start there, eliminate several of them, and try starting with and without different combinations of the 4, see if you can determine if one of the 4 is malfunctioning within your system. It seems unlikely, but we need to start by eliminating them as suspects. @bonienl may want to monitor this, in case there's an issue with them. There are a few odd workarounds in your syslog, so try checking for a newer BIOS version. It probably won't help, but it's one more suspect we can easily eliminate, if there's a BIOS update.

Just general comments, no personal experience with CP - I suspect you aren't getting any response because it's a new problem, unrecognized, and no one knows anything useful yet to tell you. That seems consistent with a buggy CP update, so I would look into any newer updates that hopefully patch it, or look into reverting to a previous version that worked. If it's true that it's because of a buggy upgrade, I would remind users that experienced and veteran computer users NEVER accept immediate upgrades, and turn off auto updates, and always wait a reasonable amount of time before updating anything. You always want to allow others to test it first, find most of the problems first. ALL software is beta on your system, until you personally have tested it, and that's only after it's had as wide a testing as possible by others. But we all have our individual preferences, bad experiences, and degrees of risk aversion.

I don't know if you have seen the Guides and Videos page. We have some good guides in there, and we have great people who keep making more of them.

I have no personal experience, don't use a cache drive, but what you suggest sounds correct. Toggling Turbo Write on should speed up Cache:Yes moves (but not Cache:Prefer moves). However, some perspective would be good. The Mover is designed to do these moves at a time when the system has the least usage, generally an early morning moment when you know everyone of its users will be sleeping. So do you really care how fast it is then? You're sleeping! What you might care more about is that a number of additional drives had to be spun up too, that normally would have been sleeping too.

Added to Guides and Videos!

That's Disk 19, sds, and there was a read error of a contiguous block of sectors near the very start of the drive, which probably resulted in 32 read errors showing on the Main page for Disk 19. The SMART report is nearly perfect, no errors at all. Its only problem is the age of the drive, with over 66000 hours on it. But its aging well, no VALUE's below 100. I don't know why the read error occurred. It indicates an issue with the physical media, but the SMART data in this diagnostics is not reporting any problems. Try a SMART short test, then a SMART long test (follow the instructions on how long to wait for each).

FYI, Network NAS is not really a term, as the N in NAS is for Network. So Network NAS would stand for Network Network Attached Storage. Any NAS is networked.

This is just my opinion, and based on poor memory too... I don't like either of those options (not what you want to hear!). I think both of those numbers are too optimistic. As I recall (and I could be wrong), PCI transfers were not bidirectional like the SATA speeds, so you would have to split them in half or a lower. I suspect a true max for 4 simultaneous transfers on PCI would be closer to 15MB/s. But of course, you are rarely ever doing simultaneous I/O, except during parity operations or drive rebuilds. When it's I/O to only one drive, which is most of the time, then you are back to full speed. And Port Multipliers have always been very disappointing I think. I don't recall ever hearing someone very satisfied with them, both for performance reasons and for reliability reasons. Many Port Multipliers claim to support 5 drives, but the first or fifth drive would either be inaccessible, or would drop out periodically. Again, it's been quite awhile, my memory could be very imperfect... I'm also not sure you can find a SATA III port multiplier. Most are older, require something like the SiI3132, which has its own top limits, is SATA II. I think BobPhoenix's ideas are much better.

Great to see you back! I suspect once you hop back on the bike, it will all come back pretty quickly. But take your time, as I'm sure you have learned, some things are more important than us! I also suspect you will have lots of willing helpers, ready to test anything you want tested. It's always good to make anything that's of value to the community readily accessible and editable by the community. But we will still need and want you in charge of it!

@gfjardim, this (no need for screen any more) sounds like a good candidate for a Q & A, in your first post.

And since we're on the subject of feature requests ... First, thanks for adding TRAY_NUM to the historical lists, and for the Areca support! This one is an expansion of the historical slot number, and isn't strictly necessary, now that you've added the slot number. But the nice thing about this plugin is that it establishes the relationships between the virtual drives and the physical drives. In keeping with that, it would be nice to still see the unassigned or disabled drive still in its slot, where it still physically is, even if the kernel can't see it. Perhaps grayed out? It wouldn't have drive numbers or device symbols, but would still have its physical identification. Then we would need a blanking action for slots, that corresponded to the physical removing of a drive. A second request, this one is a small issue. Your plugin is one of the few sources of confusion about what is spinning and what is not on the Main page. When SMART requests are done, they spin drives up (unless the drive is a WD), but the SMART request does not notify unRAID (emhttp?) that the drive is spinning. So temps appear, but the drive cannot be spun down, because the system still thinks it is spun down. You have to manually spin them up (even though they are actually already spinning), before you can spin them down. Not sure of your best course, but perhaps issue an unRAID call to spin all drives up? That will keep spin states correct.