JonathanM

Latest working fine here. Maybe post your docker run?

There is a fairly high likelihood you will break Unraid doing that, if not now, in the future. The individual tools may or may not be compatible with later releases, causing all sorts of strange errors. If you need a specific package, either request that it be added to the nerd tools plugin, or if that isn't feasible find or compile a version compatible with the current Unraid slackware. The reason this plugin isn't updated is because of all the work needed to keep everything up to date and compatible. If you try to force old packages you will cause problems for yourself.

Attach diagnostics zip file to your next post in this thread.

Yep, that was the issue.

Update to 6.11.3

It works for thousands of people. You insist it's the OS fault, but it works fine for the vast majority of folks. Very few people sign up to the forums just to say things are working well, so you mostly just see the issues. Yes, there are some combinations of hardware that cause issues, but Limetech can't control that, all they can do is offer suggestions of what hardware seems to work well. The worst part is that hardware list is a moving target, as the linux kernel evolves and new products come to market.

Attach diagnostics zip file to your next post in this thread.

The automated process already puts the current OS files into the /previous folder before it puts the upgraded OS files in place. Making a full flash backup needs extra time and a destination with enough space, I guess you could start the upgrade and cancel the download of the backup if it didn't suit at that point. Or maybe offer it as a recommended option during the upgrade, with the option to bypass? Or, you know, trust people to do the right thing and keep regular backups? 🤣 Yeah, I know.

I agree, 6.11.2 should never have made it in to the wild.

Also AMD systems need special care with BIOS settings, in particular make sure the power supply idle control is set for compatibility, and RAM timings are NOT XMP overclocked. Just because the RAM is rated for a given speed doesn't mean the motherboard and CPU can drive it that hard error free. There is a post on this forum about solving AMD specific issues.

Recognizing the drives isn't the issue, it's random I/O errors. Doesn't happen with all Marvell controllers, just something to watch out for.

Upgrade to 6.11.3

Some Marvell controllers can be problematic with Unraid. Unraid OS loads into and runs entirely in RAM. The booting license USB holds the OS archive and settings that need to survive reboots.

Connect them to a PC, do a long SMART test, and look at the results. This is the generic answer as to how to best utilize drives of unknown status. You must first determine to the best of your ability how trustworthy the drive is.

Smart reports?

Yes, the only new config and parity build that needs to be done is when you are finished copying data around and wish to remove drives. If you want a more detailed plan of what gets copied where and what order to do things, you should post drive by drive list of capacity and usage currently desired end state drive list. for example I now have 14T parity1 14T data1 - 10T XFS 3T data2 - 2.9T XFS 3T data3 - 2.5T ReiserFS I want to end with 14T parity1 14T data1 14T data2 - contents of old data2 and data3 Putting this type of layout into print allows us to figure out the best way to get from A to B pretty easily with step by step easy to follow instructions that you can check off as you accomplish them.

Do you have daily diagnostic emails from when the server was running?

That's where you are mistaken. In this example the disk we are discussing is perfectly fine, the fault lies in the communication path, not the drive itself. Cables, HBA, bad RAM, all can cause bits to not make the trip intact. No. The write keeps parity in sync. If the write is NOT completed successfully, parity is no longer in sync with the disk in question so the disk must be removed from the parity equation. If the read failed, the parity equation is used to determine what should have been returned. Absolutely correct. It's the situation where continual retries fail that causes performance issues. The SATA command chain ALREADY does multiple retries internally before it throws in the towel and says the data is unable to be read or written. Once that happens, Unraid assumes the hardware did its job correctly and acts on the result. Yes, that happens fairly regularly. But until the problem that caused the data to not be read and written correctly is solved, there is nothing Unraid can do about it. Either the drive acknowledged a successful write or it didn't. Whether that's the drive's fault or not isn't relevant to this discussion.

The problem is Unraid can't determine WHAT made the write fail, only that it did, indeed, fail to properly record the write that was sent to it. The drive is most likely not at fault, but the fact remains, Unraid sent data, the drive was unable to send back the signal that the write succeeded. Whether it was a loose cable, a HBA burp, RAM corruption, whatever, doesn't really matter to Unraid, the fact remains that data sent to the drive wasn't acknowledged, and must be treated as lost. You are correct in that decisions were made to expedite the continuity so there is as little disruption to the flow of data overall as possible. I suppose it could be possible to change that behaviour so the data stream would grind to a halt while Unraid tries multiple times to get communication going again with the drive, but I suspect you would have even more complaints about how slow Unraid is at file I/O. Bottom line, a healthy system just doesn't have these sorts of issues. A read is issued, the data is returned. A write is issued, it's acknowledged. If that doesn't happen, the issue that's causing the problem needs to be addressed.

If a READ command fails, Unraid returns the parity calculated value and attempts to WRITE that value back to the drive where the read failed. If the write succeeds, the "errors" column is incremented, and things continue. If the write fails, Unraid disables that disk, and all further read and write operations to that data slot are calculated and implemented using parity. So, it is quite possible to have a data read operation result in unraid disabling a disk, but only if the address that failed the read ALSO failed the resulting write.

I use UrBackup.

Since it's a separate boot option anyway, normally it's just recommended to use a different USB flash drive for the latest memtest. It may be possible to add the new version manually to the Unraid stick, but it's not something I've seen done.

Something like this http://www.add2psu.com/ would automate the process. Make sure the power supplies have a good common ground connection, one good method is a wire with ring terminals on both ends connected to the mounting screws on both PSU's.

Open the archive on your desktop and extract the relevant folder.

When was your last parity check with zero errors?