JonathanM

That means the GUID is not unique, typically cheap no brand sticks will all use the same GUID, sometimes even name brand sticks will do it, in any case the GUID must be unique to qualify for a license.

What happens if you use the original stick that the license was issued to?

If you have the key file that belongs with the stick, it should just boot up and show as licensed. Are you sure that's the only key file in the config folder? Attach diagnostics to your next post in this thread if it doesn't work.

First google hit for unraid iscsi.

Put it in the config folder instead of the root.

Do any of your containers have custom IP's?

If your power supply can't handle spinning up all array drives simultaneously your only recourse is to disable spin down. Consider this scenario, which is rather common. A read fails on a drive. Unraid immediately spins up all drives, calculates what should have been returned from the failed read, and writes it to the drive as well as returning the data successfully to the calling process. If the write succeeds, the error counter for the drive that failed the read is incremented, and everything moves on as normal. If the write fails, the drive is red balled and all further writes to that data slot are emulated with the rest of the drives and parity. That is exactly the worst possible time for a power supply to sag, as it will likely cause multiple drives to fail their read, causing chaos, very likely corrupting data. Either be sure your PSU can handle all parity protected drives spinning up simultaneously, or disable spin down. No other RAID solution allows pool drives to spin down individually, so it's just the price you pay to use Unraid's extra capabilities.

It should speed up when it passes the 3TB mark, right now it's hitting all the drives as it's below the 2TB line.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-819173 "stock" speeds can be too fast, depending on which specific processor and the number and type of sticks. Also, some brands of sticks just don't like some motherboards, are your sticks specifically validated by your motherboard manufacturer?

Are you by any chance running a Ryzen CPU? If so, make sure your memory is not running over the CPU spec. Typically the RAM chips speed rating is WAY higher than what the CPU can manage.

The limits are whatever applies to the specific card, whatever Nvidia dictates. See the first post in this thread for further clarification.

That's only applicable for BTRFS pools at the moment. I personally use XFS for my cache, as it is a single drive, and I have had better experience with XFS.

Better now?

Parity has no concept of files, so it's going to write the entire drive capacity regardless of content. It will take a while. However, once it's passed the 3TB mark and it's no longer using the old small drives it will speed up considerably, so you can't really estimate the total time based on the first part. You can just do 1 parity check after both parity drives are replaced. 4 days is going to be tight, you may end up leaving the old drives as part of the array even if you get the data moved, and wait for the new config, drive removal, and parity rebuild and check until your next opportunity.

XFS is fine, with dual parity you can do 2 at once, whether you want to risk it is up to you. How confident are you in the health of all of your drives? If building and checking parity goes seamlessly, I'd personally be comfortable doing 2 at a time. You should do a parity check after the parity build on the new drives, just as a confidence check.

Why? After you have your parity drives upgraded you can simply replace data drives with new ones and parity will recreate the file system. Or are you trying to change file formats at the same time?

While it would work, it's also one of the least efficient ways of doing it. You could rebuild the two drives with the most data on them from parity, then copy the rest of the drives to the newly rebuilt and expanded drives. BTW, if you read the thread I linked, there are some very good reasons for NOT moving the data, but instead copying it. One very important consideration here is whether you have current backups of everything. Moving around massive amounts of data is a very good way to make a mistake and lose data.

Manually using the command line https://forums.unraid.net/topic/115086-trouble-with-removing-drives/?do=findComment&comment=1046060 That's a thread where someone recently did exactly what you are doing. Or using a GUI https://forums.unraid.net/topic/43651-plug-in-unbalance/?do=findComment&comment=428828

Are you going to copy the data elsewhere before you remove the drives?

I'm even more distrustful of an online vendor that says they operate out of a single family dwelling. Smells scammy. https://www.google.com/maps/place/68+2nd+St,+Edison,+NJ+08837/@40.537622,-74.3374659,3a,75y,112.12h,90t/data=!3m6!1e1!3m4!1sqhLVIocTMQ_iwfwcObNRPg!2e0!7i16384!8i8192!4m5!3m4!1s0x89c3b63d33a168f5:0x95459e21d5e2d4b6!8m2!3d40.5375394!4d-74.3372334 Also, compare https://pcneeds.us/refund-policy/ to https://serestcollar.com/refund-policy/ Really strange that the pcneeds site would use the same phone number as a flea and tick collar supplier.

Do you have any ports forwarded through your router, or is your server in the DMZ?

Depending on the exact usage, there may not be ANY performance penalty, even in a x1 slot. It all depends on how the GPU is being used, if the job you are asking is 90% processing cycles and 10% i/o, it probably wouldn't even matter. Mining using GPU uses so little i/o that PCIe x1 is perfectly fine, no performance penalty at all. I suspect transcoding is somewhere between mining and 3d gaming, probably on the mining end of the scale.

Have you shut down and restarted the array? Attach the diagnostics zip file to your next post in this thread.

It has a physical x16 length, but I'm pretty sure if you open the end of the slot it would even work in a 1x slot, at 1x speed. PCIe is special that way. Random google result https://dfarq.homeip.net/x16-gpu-in-pcie-x1-slot-the-caveats/

Hard to say, usually it's fine, but some motherboards seem to be really picky about USB sticks.