thingie2

I'll disable spin down for now then & retry once the array is rebuilt. I've also found my PSU had an additional SATA PWR cable available that I wasn't using (I was using a couple splitters before), so I've replaced one of my splitters with the new cable coming from my PSU, so the only splitter I'm now using is a 4-pin -> sata for my 3x SAS drives (and this is needed, as it seems the drives have the 3.3v disable function, which this gets round) Is there anything I can do to try & narrow down why there are issues with spin up? I did think there were a few drives that weren't spinning down yesterday, so I "reset" their spindown setting (changing the value to never, then back to default), which seemed to make them spin down again. I assumed it was just a random thing that they "forgot" their setting, but maybe they're related? I have recently installed the sas spindown plugin, which has worked to spindown my sas drives, but could this have caused a problem for the sata drives?

A further update - Woke up this morning to the same 2 drives (3&5) having a couple errors each. I stopped the array before thinking to download diagnostics, but attached them with the array stopped, and also attached diagnostics from restarting the array in maintainance mode (to hopefully prevent any issues), before a system restart. I'm curious with it being the same 2 drives, but being multiple drives, it seems unlikely to be both drives suddenly failing again. I'll have to check if both drives are on the same port in my SAS expander, and if it is, I'll try a different port, unless there's anything else I should be looking at? tower-diagnostics-20251204-0852.zip tower-diagnostics-20251204-0834.zip

I've been upgrading some of my disks with larger ones, and ran a preclear on the new disks before adding to the array (mainly to check for failures), then when adding to the array, replacing an old (smaller) disk, it still needs to write to the whole new drive capacity. Proposal: If unraid detects a preclear signature on the new disk, the replacement only takes as long as writing the original disk's capacity to the new drive. E.G. replacing a 4TB disk with a 16TB disk, if the 16TB disk is precleared, then there's only 4TB of data to copy to the new disk, with the remaining space already being zeroed (due to preclear), therefore parity will already be valid. This would then take 1/4 the time to add.

Update to this - Rebuild completed sucessfully & I ran a check with the file integrity plugin & although it picked up a few files they were all ones that will be easily replaceable, or seem to be false flags (manually reviewing the media files, all looks OK). Thanks for all the help in getting my setup back up & running. Back to preclearing my new drives, ready to install into the array.

Based off your previous response, I decided to just go ahead with a rebuild, however when trying to rebuild, I'm getting stupidly slow speeds (seems to be averaging at most 5MB/s), so it'll take weeks to rebuild, which is far slower than I've ever had rebuilds before. Is there a reason it'll be going so slowly & is there anything I can do to speed it up? EDIT: Nevermind, after about 15 mins, the speed seems to have jumped upto ~180MB/s

Excellent, thanks for all the help! That's where I was looking for the L+F, so doesn't seem like I missed it. Is it any issues with one of my parity drives saying it had an issue originally, or has everything we've done here resolved that somehow?

Great, thanks, the array is now mounted, but it's only showing 2 drives with issue (but initially my setup seemed to think there was an issue with one of the parity drives to, but it seemed to think that's ok now. Am I safe to re-build the data on the 2 drives with failures? I've attached my diagnostics, now everything is mounted.tower-diagnostics-20251124-1814.zip EDIT: I also don't seem to have a lost+found folder. My understanding is this is created on the disk that had issues, and I should be able to see it by browsing to it via the "main" tab, is that correct? If so, I'm guessing that's good news?

Great, I've zeroed the logs & fixed the FS. I've attached the output of the FS fix in case it's helpful & reuploaded the diagnostics: Disk 3 FS fix.txtDisk 5 FS fix.txttower-diagnostics-20251124-1720.zip

When trying, I get: Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.As there's a mention below that I can't mount the FS without clearing the log, I guess this is what I have to do now, but I wanted to check in case there's something else I should do first?

If I check the FS for the unmounted drives, for both drives I get: Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now. Should I run the "Fix" for the FS?

Sorry, I completely misread that as "after restart"... Here's diags after I've started the array.tower-diagnostics-20251124-1442.zip

Thanks for looking. I've just been through my cables. All looked OK, but I've unplugged & re-plugged every data & power cable to make sure it's seated properly & I've swapped the couple of drives with issues to other cables. I've also added a fan directly over the expander's heatsink, as it won't hurt & I think the airflow over it was probably fairly minimal in the new location. Here's my new diagnostics. tower-diagnostics-20251124-1404.zip

Cheers, I was hoping & expecting that to be the case, otherwise it's just really bad luck & timing. I'll check through cables etc. I did add an extra splitter for the new drives, but I wouldn't have thought that would effect the drives already connected to other cables, would it? Is there any way to check if it might be HBA/expander heat related? They've both had fans pointing in the general direction of their heatsink, but I just rememebered I moved the expander a bit to make space for the extra drives, so it might not have the same airflow over it. Could it be heat generated from all the throughput (I was seeing ~2GB/s total continuous throughput across all drives going through the expander & HBA whilst the preclear & rebuild was going on, and normally I'm not at more than a couple 100, and even that is fairly sporadic), causing it to throttle/crash etc? Also, what's my best bet for restoring from here? I understand if I have an issue with 1 or 2 drives, I can just get the array to rebuild, but what do I do with 3? As the number of errors was fairly low, can I just assume my data is OK & get it to just rebuild the parity off that (if so, is that done with the "new config" option?). Once this is done, would it be reasonable to run the Dynamix File Integrity plugin to check which (if any) files have been corrupted, so I can restore those from backups?

I got a few read errors on one of my parity drives (parity 1) yesterday overnight, which I thought was a dodgy connection (the SATA cable wasn't quite fully seated when I checked in the morning), which I begain rebuilding yesterday morning, but overnight last night, I've had that drive & 2 other drives have read errors. The only thing I've changed is I've added 3xSAS drives, which I have been running a pre-clear checks on before adding to the array. Can anyone with a better understanding of diagnostics give any pointers to what's causing the errors, how I can avoid them & how I'm best recoving from the errors (AFAIK all my data is either replaceable (general media), or is backed up (personal photos, documents etc), so shoudn't be the end of the world if I have actually lost data, but would be a lot easier if I haven't. Currently Unraid V7.1.4 I've currently stopped the array to prevent any further errors, until it's resolved.tower-diagnostics-20251124-0833.zip

Thank you all, I assumed the "child" containers needed rebuilding due to the Gluetun container ID changing (or at least being something similar to that), but thought that I must be missing something, as Unraid sorts it all automatically if I browse to the docker tab, but it would make sense why it doesn't do it otherwise, if it's a frontend fix/workaround, rather than a core functionality. @strike Thanks for pointing me to that container, that looks to be exactly what I need, so I'll give it a go.