ConnerVT

Try this: watch -n1 "grep \"^[c]pu MHz\" /proc/cpuinfo"

At least we can post again. Earlier I could browse, but was unable to enter text in the Reply box.

I usually wait until the chatter for the new release simmers down. There still is a bit regarding macvlan/ipvlan, networking and crashes that keep me from embracing 6.12.x for now on my main, critical server.

What you needi s a bit up from your link: Parity Disks

Cloudflare Tunnels are encrypted, just like VPN tunnels, except are only encrypted between the Cloudflare servers and your endpoint server. With CF Tunnel, the data between your client device and Cloudlare server is not encrypted (other than typical https SSL). I use Cloudflared for accessing a number of docker services and some other devices on my network, but haven't yet reached the confidence level of exposing the Unraid server interface itself. For those services that I want an extra layer of security, I've been adding 2FA through Cloudflare's Zero Trust > Access > Applications.

You have a couple of questions here I'll give some input on. USB backup - I do this on my main server. The server itself holds backups of several other systems/computers. Weekly I back this data onto a USB drive (drive connected to server via Unassigned Devices plugin). I have written a pretty basic script which uses rsync to copy the folders to back up to the USB drive. I have two USB drives, and once a month I'll swap them, taking the unconnected one to store offsite at work. Spinning down USB drives - This is pretty hit or miss. It mostly depends if the USB-to-SATA controller in the drive enclosure supports this. I suggest you Google and do some research. If you don't plan on swapping drives (as I do to take off-site) it probably is would be simpler to add the drive as a pool and let Unraid control the spin down. Appdata backup - Easiest would be to use the Appdata Backup plugin. (get the latest version of what is compatible for the Unraid version you are running) I back up my Appdata to my array, and then it is one of the folders I back up to the external USB drive.

I have been running Plex for several years now (since Media Browser switched over to Emby. 2017?). I have only needed to delete codecs a few times. A couple when my Plex server was running on a Windows machine, maybe once on Unraid. So it is not (and shouldn't be) something that happens frequently - If it is, I would check for some other underlying issue. But it is something that can be difficult and frustrating to troubleshoot if you aren't aware of the possibility. I found out about this from mining the Plex forums years ago (back before they changed their forum style). From what I have seen in the Plex forum, and the number of responses I've had here in the Unraid forum, it has been the solution for quite a few people to solve their transcoding/playback issues.

Impossible to answer. It isn't so much what you will be serving, but how much you will be serving. For a non-business server, will you really be serving 100 TB/month?

A Two-for-One sale! Excellent!

Thanks for that. From the dashboard, I was hunting through System Devices and the System Log (which no longer has the boot sequence from a month ago). I was poking around the diagnostic files, but never revisited syslog, as I had looked at it from the dashboard. Now I know the file has all the logs from start of boot, and is not truncated. Good new is that Kingston SSD is an ancient drive, one I've had for nearly a decade. I use it as a transcoding temp location, as I really don't care if it fails, as it has more than given me my money's worth of service.

Just saw these in my syslog from last night. Been poking around, and I can't seem to figure out which drive is ata6.00. Diags attached below. Thanks! Jul 25 22:29:38 Malta-Tower kernel: ata6.00: exception Emask 0x11 SAct 0x30e0 SErr 0x680100 action 0x6 frozen Jul 25 22:29:38 Malta-Tower kernel: ata6.00: irq_stat 0x48000008, interface fatal error Jul 25 22:29:38 Malta-Tower kernel: ata6: SError: { UnrecovData 10B8B BadCRC Handshk } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c0:28:00:1d:01/02:00:00:00:00/40 tag 5 ncq dma 360448 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/40:30:c0:1f:01/05:00:00:00:00/40 tag 6 ncq dma 688128 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c0:38:00:25:01/02:00:00:00:00/40 tag 7 ncq dma 360448 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/f8:60:c0:27:01/06:00:00:00:00/40 tag 12 ncq dma 913408 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:38 Malta-Tower kernel: ata6.00: cmd 60/c8:68:b8:2e:01/00:00:00:00:00/40 tag 13 ncq dma 102400 in Jul 25 22:29:38 Malta-Tower kernel: res 40/00:68:b8:2e:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:38 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:38 Malta-Tower kernel: ata6: hard resetting link Jul 25 22:29:39 Malta-Tower kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: configured for UDMA/133 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#5 CDB: opcode=0x28 28 00 00 01 1d 00 00 02 c0 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 72960 op 0x0:(READ) flags 0x80700 phys_seg 88 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#6 CDB: opcode=0x28 28 00 00 01 1f c0 00 05 40 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 73664 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#7 CDB: opcode=0x28 28 00 00 01 25 00 00 02 c0 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 75008 op 0x0:(READ) flags 0x80700 phys_seg 88 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#12 CDB: opcode=0x28 28 00 00 01 27 c0 00 06 f8 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 75712 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 Sense Key : 0x5 [current] Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 ASC=0x21 ASCQ=0x4 Jul 25 22:29:39 Malta-Tower kernel: sd 9:0:0:0: [sdg] tag#13 CDB: opcode=0x28 28 00 00 01 2e b8 00 00 c8 00 Jul 25 22:29:39 Malta-Tower kernel: blk_update_request: I/O error, dev sdg, sector 77496 op 0x0:(READ) flags 0x80700 phys_seg 13 prio class 0 Jul 25 22:29:39 Malta-Tower kernel: ata6: EH complete Jul 25 22:29:39 Malta-Tower kernel: ata6.00: exception Emask 0x11 SAct 0x1e000 SErr 0x600100 action 0x6 frozen Jul 25 22:29:39 Malta-Tower kernel: ata6.00: irq_stat 0x48000008, interface fatal error Jul 25 22:29:39 Malta-Tower kernel: ata6: SError: { UnrecovData BadCRC Handshk } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/00:68:80:6f:01/0a:00:00:00:00/40 tag 13 ncq dma 1310720 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/f0:70:80:79:01/05:00:00:00:00/40 tag 14 ncq dma 778240 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jul 25 22:29:39 Malta-Tower kernel: ata6.00: status: { DRDY } Jul 25 22:29:39 Malta-Tower kernel: ata6.00: failed command: READ FPDMA QUEUED Jul 25 22:29:39 Malta-Tower kernel: ata6.00: cmd 60/00:78:70:7f:01/0a:00:00:00:00/40 tag 15 ncq dma 1310720 in Jul 25 22:29:39 Malta-Tower kernel: res 40/00:80:70:89:01/00:00:00:00:00/40 Emask 0x10 (ATA bus error) malta-tower-diagnostics-20230726-1050.zip

Innostor is the company of the disk controller of the flash drive. My best guess is the company that produced the completed flash drive (Platinum?) saved a few cents, and did not bother to generate/program unique GUID for the drives, but rather left it set to how they received the controller chip from Innostor. So there are likely tens of thousands of these drives out in the world, all with the same GUID, and one of them was already used for an Unraid boot flash drive.

Not a lot of details here to make a solid suggestion. But it reminded me of a quirky thing I saw when setting up a backup server. I have an old GT 710 I put in that server, just for setting it up, configuring BIOS, etc. I noticed that one core would pin to 100% after waking it from sleep (server boots to Unraid GUI). I found that the proc XORG was causing that core to max out. As I had no plans to use the GPU for anything other than the Unraid dashboard, I hadn't bothered installing any driver for the GPU, and it was functioning as needed without it. I ended up installing the Nvidia driver and set nvidia-persistenced, and it is now no longer an issue. I don't know if this will help any, but something you can look into.

Do you have a monitor plugged into the Nvidia card? I had a similar issue some time back, where it would only boot when a monitor was attached. I ended up plugging in a HDMI dummy plug, as I did not wish to keep a monitor on the server. https://www.amazon.com/gp/product/B071CGCTMY

Shooting from the hip here. Looks like Plex having an issues during audio scans (probably during maintenance). If it were me, I would delete all of the files in my Plex codecs folder. This is a common fix for funky encoding issues with Plex, which has been going on for years. Your Plex application will download and reinstall a fresh copy of the codecs automatically. I typically stop the docker, delete the contents of the folder, then restart the container. It may solve the issue. It may not. But worth a try.

I am still looking forward to this happening.

In your case, probably not (see my post above). But Microcenter, like any retailer, is only as good as their supply chain practices. Ten years ago, you would have said the same thing about Newegg. But now that they have become a "marketplace" reseller (as is Amazon), products can be intermingled. I'm sure that Microcenter does not deal with SanDisk and Samsung directly, but buy commodity products such as flash drives from a wholesaler. And these types of products are usually bought looking at who has the lowest price at the time of the order. If you buy a RX4090 from Microcenter, odds are better than 99.9% it would be genuine. can't say the same for a $10 flash drive. I work in semiconductor manufacturing. each year I need to re-certify a training on secure supply chain logistics. Counterfeiting is a big issue in the industry.

Some USB sticks come pre-formatted in funky manner - May have extra partitions which contain backup software, or are just generally strange. I've seen the USB creator tool tends to have issues with this. Wiping the drive clear of all partitions (Windows Administrative Tools -> Computer Management -> Storage -> Disk Management) will usually remedy the issue. Note this not only happens with Unraid's USB Creator. I have had similar issues using the Raspberry Pi Imager, Rufus and other ISO type imagers as well.

20TB isn't an extreme amount to move. Not the fastest to move across a 1GB LAN, but not totally unbearable either. I'll suggest two different options: 1. Treat the new server as a hardware upgrade - Think of it as replacing the CPU/MB/Power Supply/Case. Put the drives from your current server in the new system (including any cache/pool drives). Before shutting down your old server for the last time, be sure to update any plugins and turn off the Start Array Automatically as well as VM and Docker services. Boot from your current licensed flash drive, and sanity check that all runs correctly as expected. Move on to starting the array, Unraid should remember your drive configuration and start normally. You can then start up Docker, and this should also start normally, as your appdata is still in the same place as it was in the old server. Once the system has proven itself functional and stable, you can start swapping out the disks. Start first with the Parity Drive, and let parity rebuild. Then a data drive, and let that rebuild. After this, you can move data from old drives to the new one (assuming there will be less drives in the new system than the old) or just swap in another new drive. (Unraid Docs for details) Lather, rinse, repeat. Some benefits of going this route: Limited amount of down time (as array will be accessible through emulated disk during rebuild); stays true to your current configuration (less chance to name/config something wrong and messing things up); data always 100% in sync between old and new servers during migration transfer; old server drives are in hand as an effective backup in case you have any issues. 2. Create Trial USB for new server - You can build the new server hardware with all the drives as you want in the final server. Create a Trial USB for the new server. Then you need to configure it all. Afterwards you transfer all of the data from the old server to the new server. You can do this via you LAN, or using Unassigned Devices and pulling a drive from your old server, put it in a USB enclosure (or attach internally in the new server if there are available connections, IMHO a PITA) and copy the data. Continue until all is transferred. (Note: You will want to either enable Turbo Write or just not enable your parity drive until all is transferred). After all is done, you can copy the contents of your new trail flash drive over that in the license one (SAVE your *.key file from the old USB config folder first!), then copy the license back to the original flash drive. The benefit of doing it this way (at least, copying by LAN) is zero down time of the server. But it doesn't guarantee the data will be 100% in sync, as a file/folder you copied at the beginning of the process may have been updated/added/changed before all is done copying. But personally think that this is way more prone to error.

It is usually a crap shoot trying to diagnose why without a diagnostic file or much info to go on. Assuming there are no other issues (except for the errors mentioned on the drive being replaced, which shouldn't have any affect), my first guess is that there was some read/write activity happening in the array during the rebuild. That's assuming the ~30MB/s was happening during the rebuild stage. Speeds during parity check/repair and drive rebuild can be funny when there are different sized drives in an array. I'll use my array as an example, which has both 8TB and 16TB HGST drives. Drives access faster on the first tracks, slower on the last tracks. My read access is basically 250MB/s to start, 150MB/s at the end. Obviously when you write, it is slower (and slower still when calculating and writing (parity or data). It takes a few moments for the reads of multiple disks to sync up, then will start off at the fastest speed (250MB/s). As I have 8TB and 16TB, the speed will track that of the smallest drive (8TB), so for the first 50% of the process, speeds will track down to 150MB/s. After it is done needing to access the 8TB drives, the speed will jump back up to 200MB/S, ramping back down to 150MB/s at the end. (Remember this is parity check speeds, read only. Obviously much slower for read/write parity or data rebuild). If there is any sort of array activity happening other than the rebuild operation, the synchronization of the reads gets messed up, so the drives thrash around a bit, really slowing down the drive rebuild.

It is difficult to give advice on a best plan without more details. How much data are you needing to move? Does the current server need to be up and available, or can it be down for some time? Are you putting all new drives in the new server, or will some/all of the drives in the current server end up in the new server? Every migration is different, depending on the situation. The devil is in the details.

A little OT for this thread, but don't assume the fault lies with these player. Could easily be that this version of Plex is at fault, and not playing nice with them. You might want to try an earlier revision of Plex (ideally, one that is known working correctly) to see if this helps. This is one reason I don't jump on the latest Plex release. Those guys always break something when adding something new and shiny.

One additional strategy - Buy a new "old" model of a major, popular brand. Counterfeiters aren't likely to knock off fakes of low capacity and/or "slow" USB2 flash drives. There isn't any money in it, as the buying public is usually looking for "BIGGER! FASTER!" drives. There is little reason to use flash drives over 8GB for an Unraid boot drive - plenty of room for Unraid, and not best practice to use it for other storage as in increases wear and may reduce the drive's lifespan.

I was today days old when I found out about this. Thanks!