n0stalghia

I see, so I would have a redundant internal boot drive and a combined 612 GB that would fail if any of the drives fails, correct? Hm, seems almost worth doing, as my cache currently has no redundancy anyway. Thank you for the insight!

I currently have a 500 GB SSD that I use as cache. I also have an older 128 GB SSD which was used as cache in the past, but currently is collecting dust. Now, there's this exciting new internal storage. Let's assume a boot partition of 8 GB. I was wondering if it's possible to do the following: Use the 500 GB SSD for internal boot + cache Use the 128 GB SSD for internal boot + cache, mirroring the 500 GB's boot partition (not mirror the entire drive - only mirror the boot partition) Use the leftover 492+120 GB of data for a total of 612 GB of cache (roughly) Specify that 500 GB SSD is used as cache first, and the 128 GB SSD is only written to when the primary cache is full or the 500 GB SSD fails Specify that the OS boots of the 128 GB SSD and falls back to the 500 GB SSD when the primary boot drive fails What of the above is possible? Thanks!

Check whether your Primary/Secondary storage for the share is set up correctly. Cache must be Primary, Array must be Secondary. My config that I've had for several years reset itself, either after upgrade to 7.0.0 or when I upgraded my legacy license to Unraid OS Pro. Possibly related:

Well that's weird. I've not touched this setting since 2020 or 2021, basically, for several years. I've set it up now to use Cache as Primary and Array as Secondary, as it was before, and the Mover runs. Why did it reset, I wonder? Well in any case, thanks for the quick sanity check, it seems to work now.

Immediate disclaimer: I do not use, and have never used, any Mover Tuner plugins. I've received the following e-mail notification from my Unraid server tonight: Upon further checking, I tried to invoke the mover manually, and it didn't do anything. I turned on logging, and this is what the log shows: Mar 2 10:24:57 Uxie emhttpd: shcmd (295): /usr/local/sbin/mover start |& logger -t move & Mar 2 10:24:57 Uxie move: mover: started Mar 2 10:24:57 Uxie move: skip: /mnt/disk1/system/docker/docker.img Mar 2 10:24:57 Uxie move: mover: finished The mover starts and finishes immediately without any files being moves. The cache drive is 500 GB (355 GB full), the array has enough free space (1.7 TB/2.02 TB free on two drives, respectively). Initial Google searches have led me to problems with the Mover Tuner plugin, but I have never used it, so this can't be my issue. One thing that seems highly suspicious to me is the incorrect cache drive name in the "Description" in the notification. My drive is identified as CT500MX500SSD1_2204E600A1AA - 500 GB (sdc) in the "pool devices" section; but in the e-mail, it was listed as sde instead. I checked the previous unraid notification e-mails regarding full cache; they did indeed mention the drive as sdc previously. Another thing that is suspicious is that in my Share settings for my primary Media share, the Primary storage (for new files and folders) is currently "Array". I believe this should be Cache, no? I want my new files/folders to be created on Cache and to be moved to Array in the night. Given this information: any ideas on what could be wrong and how I can fix it?

I was not aware that parity is real-time, I always assumed it computes it during check. TIL. Well this is great news. On a "fun" side note, I tried to get a list of all data using find . -print > files.txt and the file got corrupted and threw even more mistakes - I took the server offline and already got an RMA procedure running. Thank you for the help.

Can the drive handle one more parity check, or should I power down and replace immediately? I'd lose like 3 TV series, so no big deal (all important data is backed up to the cloud every Monday)

The drive's serial number is WDC_WD80EFAX-68KNBN0_VAGY3XYL - is this one of the 7200 RPM drives that were marketed as 5400 RPM? My parity has a different number, seems to be unaffected.

SMART test is still running, EDIT: Just realized that this message also killed the extended SMART test. Errors occured - Check SMART report. I just got this message about "current pending sector" being 8. I assume nothing good? The drive is 2.17 years old, so should still be under warranty (3 years). EDIT: Added a second SMART report, this one only contains one file for some reason. uxie-smart-20210712-1725.zip

Thanks, the fast test reported no errors, the extended one will be done in 14 hours.

I've got a 2.5 years old 8TB Western Digital that has had three errors today when reading from a sector. This has never happened before. I'm not experienced in this. Is this some small random error? Is the drive dying? It's not been used too much, so this comes as a surprise to me. Are there some tests that I should run on it? Is there a shell script I can execute to try and read from those specific sectors again to confirm that the error is persistent? The disk in question is disk1 in the diagnostics. uxie-diagnostics-20210712-1628.zip