madshi

Hey guys, currently running preclear on 2 disks. The log is getting flodded with messages like these: Feb 15 21:53:13 Tower preclear_disk_ZDH1NDE7[5373]: tput: unknown terminal "screen" I started the preclear via unassigned devices plugin. In the GUI everything appears fine, the unassigned devices section shows the preclear progress correctly, but the GUI just can't show my the syslog, anymore, due to "out of RAM". Not a big deal, but thought I'd report it.

P.S: After copying in both the 2.5 and 3.0 jar files for this addon to both addons folders I have now, it started to work. I'm not sure if it's the addons folder which I added to userdata, or if it's the path assignment to "/openhab/addons" I added to the docker.

I'm trying to install this one, which classifies as a "binding", as far as I can see, but needs to be manually copied to the "addons" folder: https://github.com/jannegpriv/openhab-addons/blob/8108-vwweconnect/bundles/org.openhab.binding.vwweconnect/README.md There's no "addons" folder in /appdata/openhab/userdata for me. I just now tried creating one and copying the jar file in there, as well. Then I restarted the docker but openhab still doesn't seem to find (or use) the jar file.

Hey there, thanks for this docker, it's working nicely! I've one problem, though: I'd like to install a custom addon, and the openhab "addons" folder does not seem to be available (?). I've tried adding a "/openhab/addons" -> "/mnt/user/appdata/openhab2/addons/" path setting to the docker, but it doesn't seem to be effective. Or at least openhab behaves as if the addon I copied there didn't exist. Any ideas?

JFYI, after upgrading to a new mainboard + CPU + RAM + controller, the array is working beautifully. Not sure what the problem was. Let's assume it was the controller. In any case, thanks for your help, once more. Without your comments I would not have replaced the controller (at least at first), and might still be with an unstable array now.

Yes, I already ordered a Broadcom (LSI) 9207-8i a couple minutes ago... 😀 Will let you know how it goes. Edit: Not sure if the 2 disks were on the same controller. I have about half the SATA ports coming from the mainboard, the other from the SASLP, but I'm not sure which is which.

Yes, I tried to upgrade Disk2, using one of the 2 new 14TB disks. The new disk dropped offline after the rebuild failure. Or maybe the rebuild failed due to the disk dropping offline. Then I reboot and tried again to upgrade Disk2, using a different new 14 TB disk, connected to a different SATA port. Exact same problem. Since 2 different disks, connected to 2 different SATA ports, showed the exact same problem, what conclusions can we draw? I'm not sure... I didn't know the SASLP is no longer recommended. I bought it when it still was, a very looong time ago. I'll look for alternatives. Thanks for the tip! I've rebooted the server now and made a new diagnostic, see attachment. tower-diagnostics-20210118-1505.zip

See attachment. Thanks for looking into this! tower-diagnostics-20210118-1243.zip

tower-syslog-20210117-1620.zip History: My array was running fine, but was completely filled to the brim, so I bought 4x 14 TB drives to update dual parity and 2 data drives to 14 TB. Preperations: 1) I pre-cleared all 4 new disks with 3x pre-clear + extended smart self test. All successful, with no complaints and "perfect" smart statistics. 2) Ran a parity check to make sure that the array is "good", while one disk was still pre-clearing. But this errored out: 1st problem: The parity check started fine, but at some point it stopped, and the pre-clearing aborted, too, and the log was all "red" and full of errors. Seems something was frozen and couldn't recover. So I rebooted the server and restarted the parity check. Ran through fine this time, but found something like 270 errors or so, which it didn't find before, probably caused by the prior failure somehow. Ran another parity check afterwards, just to be safe, and it ran through with 0 errors this time. Did another pre-clearing on the new disk, as well, which also ran through fine. So I thought the problem was a freak accident and didn't worry too much about it. parity swap: Did 2x parity swap without any problems, and with 0 errors reported by unRAID. So just 2 data disks to upgrade and I'm done. 1st data disk upgrade/rebuilding: Ouch. I can't get it to succeed, anymore. The rebuilding process always starts fine, runs for a while, sometimes several hours, but then errors out, aborting with frozen complaints and stuff. I tried 3 times, with 2 different "new drives", just to be safe. See attached logs. Can you see anything useful in the logs? I think the disks are probably all fine. I suspect a controller problem or mainboard problem or power problem or lose SATA cable or something like that. But I don't know what to look for exactly. Maybe some expert here can get some useful clues from the logs? FWIW, I've already ordered a new mainboard + CPU + RAM to replace the rather old hardware. Maybe that helps fixing this up. But I'd feel better if I knew where the problem is coming from exactly. Thanks!

Ah yes, that does make sense, thanks.

That's fantastic, thank you! So I would like to reduce my feature request to a very little change: Just add the "error" information to the dual parity rebuild statistics, so that the combined dual parity "rebuild+parity check" procedure looks the same as a normal parity check. This way everybody can intuitively understand that in addition to the disk rebuild, also a parity check is performed at the same time. Which is a *great* hidden feature of unRAID, IMHO, and a nice extra benefit of using dual parity.

Oh, that's very cool, thanks for letting me know! Why is there no "error" counter in the statistics, though? Normally, when doing a parity check there's an error counter, and it's nice to see it stay at 0. Will there be an error or success report at the end of this simultaneous "disk rebuild + parity check" action that I have currently running? Can I assume that if unRAID reports no error, the state of the array can safely be considered "perfect", so I don't need to follow up the rebuild with another parity check?

I'm currently upgrading/rebuilding 1 disk. Using dual parity. I'm noticing that unRAID reads both parity disks during the rebuiling process. Wondered why that was necessary? In order to just rebuild the disk, reading 1 parity disk should suffice, no? But following that thought: If we have dual parity and are rebuilding just 1 disk, why not use the opportunity to run a parity check at the same time? So basically use parity 1 to rebuild the disk, and use parity 2 to double check that everything's perfect. That would be 2 jobs done at the same time, with the same speed and the same disk wear. Thoughts?

dlandon: Thanks. It's not a dramatic problem, just a bit ugly, so I'll just wait it out. wgstarks: I'm not doing preclear often enough to make it worth running as a docker. Thanks for the suggestion, though.

I'm still having nervous behaviour with my running preclear actions. The preclear info comes and goes every 1-3 seconds. I just uninstalled and reinstalled the unassigned devices plugin, just to be safe I really have the latest. But the preclear refresh cycle still happens.