unravelit

Thanks again for your help, you guided me through to a working solution. The parity sync completed a few hours ago, and aside from a handful of errors on one disk, all is well. That disk that had a few errors is well overdue to be replaced anyway as it has been online for over 7 years (I only realised when checking it's SMART info!). Now things have settled I can now work on replacing the parity drive with a newer, larger drive, and use the "old" parity drive to replace the very old drive... I really appreciate your patience and help. Cheers!

OK, files are there, and there is no lost+found folder Looking better! I paused the parity-sync while checking for the lost+found folder. Is it OK to resume it and now let it do it's thing?

OK, making progress, -L completed: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (67:3647140) is ahead of log (1:2). Format log to cycle 70. done I have not brought the array out of maintenance mode yet.

I really appreciate your time with this. Running the check via the GUI gave this message... Phase 1 - find and verify 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 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.

I did that, and it does not look promising... Unraid now thinks the disk has no file system I paused the parity sync stuff2-diagnostics-20231107-2232.zip

Thanks for that, it sure did. It looks like it was picked up after rebooting, and the drive looks pretty sick stuff2-diagnostics-20231107-2114.zip

Hey all, I have had unraid running for years on my trusty HP gen3 micro server. I moved the drives to a newer G7 system. I had to do a new configuration thanks to the SAS card fooling Unraid into thinking I had different serial numbers. So I after placing the drives in their correct slots, and starting with "parity is valid" checked, it was happy and I was able to see all the files. All seemed well until I worked out 2 of the 4 SAS channels in use are throwing CRC errors... Originally it was only one, so I relocated that drive to a known good bay and it was happy. Now, in what was most likely a stupid thing to do, I let Unraid start a parity sync after starting as I thought it would be good way to confirm I wont be getting any more CRC errors... So it did not go well, another drive during this sync threw so many errors that unraid has now disabled it, and the parity has paused. In looking, this drive may actually be faulty beyond my original CRC issue. So, now I feel like I am in a precarious position, as my parity is now in an unknown state and 30% of my files are not visible (e.g. unraid is not emulating the disabled drive). That is my biggest worry - that the missing drive is not being emulated... What should my next step be? I am happy to pull the potentially faulty drive and manually recover the files from it later, but am unsure of how to go about this while keeping the current setup with what left set up remaining running. I have a new 10 TB drive I was going to use to replace the parity drive once things have settled down... looks like things just are not going to my plan... stuff2-diagnostics-20231107-1410.zip

Last Chapter: So the final story is that I must have had a loose power splitter for the parity drive, which became intermittent after the data drive upgrade. Thanks to the help here I was able to sort out the parity drive, repair parity then finally install the new data drive and reconstruct it. Unraid Parity sync / Data rebuild: 10-11-2019 17:41 Notice [STUFF2] - Parity sync / Data rebuild finished (0 errors) Duration: 18 hours, 48 minutes, 23 seconds. Average speed: 118.2 MB/s All working. Thanks!

Update #2 The Parity repair completed with just under 6000 sync repairs done. No disk errors occurred. I have now put the new 8tb drive in the 2tb slot, and it is happily reconstructing. Thanks again, this is now SOLVED with no data loss. Cheers

Just an update, I was in bed last night (it was already near 3am here!) and got the message, so stopped and restarted it in write parity repair. So far, the parity drive is still healthy. no slow downs. It is at 32.9 percent, running at ~116MB/sec (normal for this rig). 7 hrs 39 mins in, 12 to go. 1158 sync errors repaired, the number has not grown in the past hour or so I have been watching it.

Thanks again for your help so far. All the drives came back looking right... and a non-write parity check is under way (and will take the normal ~19 hrs). All my disks are badly over filled, I know you are not meant to go over ~90 percent, but times are desperate, hence the 8tb upgrade Awesome help!

OK. All drives are currently in their proper places. I have never done a new config before, and not too sure what it involves (or how I can muck it up!)

I tried that, and the parity drive shows up as a blue dot drive "NEW DEVICE" I don't get an option to start the array at all with just the parity drive added as it says "Too many wrong and/or missing disks!" So it sees the parity drive, but doesn't seem to know it is meant to be the parity drive...

OK, so I pulled the little proliant out and unplugged and REALLY plugged everything back in - it is an annoyingly tight case. Aaaaand.... the parity drive is back - well, at least it is visible but not assigned. And not misbehaving right now (the spin up/down business) - so I grabbed a diag My face is red, as you can't see it. I was sure everything was fine, and have "checked" everything several times. Just ... not well. stuff2-diagnostics-20191108-1353.zip

I have checked and rechecked the parity drive connections. I will do it one more time I have email notifications set up for immediate alert - the parity drive gave me an overtemp warning (it got up to 46 degrees) today, and does on occasion when the weather is hot and no air con on. No other issues reported. I had received a normal temp alert before doing the changes. Prior to the change over work, all drives were "thumbs up" for SMART. I would try it in an external bay to try and pull smart but the one I have only supports 2tb max.