darkside40

Btw. the HDD which had the problem with the corrupted XFS FS (which i hadnt had a notification about) also was the cause for my current data loss under unRaid. The HDD seem to had some silent corruption problem which led to Parity Sync errors, which invalidates Parity during a correcting check. Means after that data loss is inevitable, because after that you can only rebuild the HDD in an unclean state. I dont know if Dual Parity etc. would have change something here. But i know now: If you have FS Problems or Sync Errors in your unRaid you are pretty lost. Especially Sync Errors mean that you have to check every component with two parity checks which put a lot of load on all components.

Okay it was not the Memory, Cable , PSU etc. it was Disk 3 which was damaged. Ran a non correcting Parity check against the rebuilded drive which ended with zero errors. Any hints how i can check the old HDD for the files which seem to be on the damaged sectors?

To be honest: no i have not tried that.

Hmm didnt unRaid flagged such disks as emulated in past releases. I know that it is emulated else i couldnt access file which are on the damaged disk. Nevermind i started a rebuild of that disk to another 8TB i have laying around here, although i know there will be some corrupted files on it because the parity i not clean. After that i will take a look on the disabled disk with ddrescue to see which files are affected. Its only media files so no big deal. Hopefully the sync errors are gone after this, because that disk was the cause.

Anyone an Idea? Tried to copy down the File normal with mc what failed. But althought the missing drive is not shown as emulated i can play the files which are on the missing drive, which confuses me a little bit. So is there any way i could use the not 100% Parity to correct the nearly dead drive?

So now Disk 3 is in Error state during the last check. How to proceed? New log are attached. htms-diagnostics-20231125-0951.zip

Okay i try switching the cable and run a correcting check.

The cables are new (data and power) and also there is no drivecage inbetween anymore.

There you go htms-diagnostics-20231124-1020.zip

My plan would now be to tra to copy the data from the disk with the Read errors to another fresh disk, place that in the array, rebuild parity and check that after that. Does that sound reasonable?

Okay the hunt goes on. Yesterday i placed all the Hardware in a new case to get rid of the old drive cages and i had to replace the old parity drive because of a broken power connector. Was working but to be sure. Than i did a Parity Sync, which completed but with 2039 Read Errors on Disk 3. If i replace the disk now with a new one and let it rebuild shouldnt there be faulty data on it in that case? I mean it show the Parity as valid, which i quite dont understand if there are read errors while building the Parity. Or does it mean that there read errors which could be resolved, by multiple readings etc?

Okay its now nearly november and nobody of the staff seems to be interested in this issue. That is extremely disappointing for such an issue. Is there any other way to reach out to @limetech etc?

So its not the Ram and it is not the Parity Disk. I replaced it beacause i thought: The failures always appear around 95% (would be great if they would begin at 1% than i could save much time) maybe the failure is somewhere at the end of that disk if its checked sequentially. Next will be the controller.

Okay. I think the first and easiest thing now it to replaye the memory, althought Memtest found no error. If that does not solve the problem i will replace the AAR1430 with an ECS06 Controller, hopefully that does not makes such problems like the last ASM1166 i tried couple of months ago. If that does not help, yeah than i have to check every single disk.

Just to be sure: all the time i change something i have to do a correcting and after that a non correcting run? Only that way i can verify i found a solution.

I can imagine. Did a XFS Check on all disks, no issues. Had a look at all Disk's smart Values only one disk had 17 UDMA CRC Errors, maybe thats the cause.

Okay took me a time had some really busy days. So i exchanged all the Sata Cables at first. Run a first correcting Parity check that 1839 errors, did a second check (non correcting) some hours later that found 978 Errors: So i dont think it was the cabling. Next would be the controller i thing with the same procedure. I also attached the diagnostics, so maybe someone with more experience than me could have a look at them and maybe find something obvious. htms-diagnostics-20231026-0714.zip

So i assume the first run must be a correcting Parity check, so that the second run should not find any errors more.

Okay i did 2 Memtest runs now. No Errors? What would be the next step? I have an alternative controller Card (Silverstone ECS06) lying around.

Yes i am sure. Okay than i will try that tomorrow, because i have to hook up a monitor or that.

Hi there, i am doing a parity check which shows my 213 errors till now. The last one also had errors but i thought that was because of an unclean shutdown before. Is there any way to see if there is any disk faulty etc? They are mounted without problems, so i dont think there is a smart problem etc. htms-diagnostics-20231011-1808.zip

Fix Common Problems will not solve it because of what i have read it will only trigger if the FS is unmountable. This will only occur if you start/stop the array, which isnt the case so often. And in my case even with the metadata corruption the FS was mountable. Also a Smart Check would have not captured the error, the disks are fine, and no they are not 10 years old. Would a regular parity check capture the problem? Dont know but in worst case you carry around the metadata corruption for four weeks before you know, if you do them monthly. On the other hand the solution would be simple, include something like the syslog notification script directly into unRaid. I mean the solution is there.

4 weeks no reaction by @limetech etc.

Yeah but you could avoid carrying the corruption around for an undefined amount of time if you know about it by simply monitoring the syslog. Like i said the hdd mounted fine in my case so thats not an indicator, and i think most people do a parity check approx. once a month because thats an operations which stresses all the disks in the array.

Three weeks, a major problem and no official reaction. Limetech really cares about the data of its users 👍