JonathanM

Hardware wise you are 100% correct. However. the number of times the tech community has had to deal with AMD systems not working well with anything not Microsoft Windows based is a long and tortured list. I'm not saying intel is perfect with linux, but AMD has a far worse reputation.

Not sure exactly what you are asking, perhaps this will help? https://wiki.unraid.net/Articles/Getting_Started#Manual_Install_Method

XMP is also an overclock in most instances, recommend you research the rated max and run that. server stability and data integrity is way more important than a few seconds shaved off of some task.

Can you ssh to that IP?

I recommended your final post in the thread so it's sticky, but you probably ought to modify the first thread post as well.

They are problematic, but I've never been charged to return a bad drive for credit or replacement. I run a preclear cycle on drives new or refurbished as soon as I get it, if it passes a preclear check, it's probably going to survive for a while. So far with the refurb 16TB I've only had to return one out of four. Yes, that's 25% failure out of the box for me, so definitely problematic, but a sample size of 4 is worth nothing statistically speaking. I'm willing to take that risk for the amount of savings available, I just test before use, and as i always do keep a close eye on drive stats, if anything looks hinky, it gets replaced and tested. I also keep 1 precleared drive the same size as parity on hand as a cold spare in the box, so I don't have to wait for a drive to ship and get tested. If the cold spare is put in use, another gets ordered and tested.

There is no urgency here, as long as you can afford to keep the source drive intact and unused, you can shelve the recovery for now and move on. Physically remove the source drive, and get us back up to date with which drives are in what state and we can help you move forward with getting the rest of the array converted.

I would set the drive to shared in Unassigned Devices and browse around with your PC, play some of the files, etc. See if it looks good beyond just showing the data is there.

Pretty sure you are in the wrong thread.

Yep. Then browse it and see what you see.

Start the array and see if the drive is mountable in Unassigned Devices.

Precisely. Just need to be careful when you transition connector styles, the cables are one way only, and they produce SATA->SAS and SAS>SATA cables that look identical but function only in the designed direction, forward or reverse breakout. 16TB SATA Exos are available as refurbs for $170 or so if that fits your needs.

Cost. Some board manufacturers cheap out assuming people won't drive the card hard enough to matter. Unraid is especially demanding of disk controllers, so it pays to get something heavier duty if possible.

Maybe try the NUT plugin?

Depends, I've had commands run for various lengths of time. I suspect it has to do with the number of files and directories it has to sort through.

Don't hold your breath, it'll kill you before the command returns. (I know, figure of speech, but just wanted to adjust your expectations) I've literally waited DAYS for reiserfs commands, but they always had a good outcome for me. Seriously, stop checking on it every few minutes. Check every couple hours or so.

Yep. no transactions found is expected, you just wrote a healthy blank ReiserFS filesystem to the device. Now it's digging across the entire partition to see what it can find.

BTW, the scan whole partition rebuild tree could take a LONG time.

Yes, formatting is a quick operation, it just sets up a blank filesystem, it doesn't actually overwrite the storage area of the disk. That's why formatting to XFS may, possibly, hopefully, be somewhat recoverable, since the actual data wasn't overwritten, just the table of contents. We just have to sort through all the raw data that doesn't have any references to tell which file is what and where the files start and end. ReiserFS is actually pretty robust at being able to recover from this sort of thing, we just have to convince it to try. All file recovery software does roughly the same thing, walks the entire surface of the disk to try and piece together files from a mess of bits with no valid table of contents. Some files have distinct markers that make it easier to figure out, but it all comes down to how well it can make good guesses as to what went where.

Well, since we are playing with the cloned device, and haven't touched the original, we can get experimental. If things don't work, we can always do the clone command again to start over. So, lets try formatting as reiserfs to overwrite the XFS stuff. mkreiserfs /dev/sdf1 Then try the scan whole partition rebuild tree command.

Try reiserfsck --check /dev/sdf1 and see what it says. Since the drive was formatted XFS I'm not expecting it to find the deleted file system, but it won't hurt to try.

Try rebooting, don't start the array, verify the sd? designation of the clone destination, and try the command again, be sure to add the 1, that's not a typo, it designates the first partition on the device.

Looks good. The "error" is expected, we didn't tell dd when to quit, so it just ran until it got to the end of the device. Now run reiserfsck --scan-whole-partition --rebuild-tree /dev/sdf1