Parity errors

[flixxx]

Monthly parity check this month (1st of every month) had thousands of errors it corrected.

 

I shutdown the server, checked the cable connections to be sure.

Rebooted and ran a parity check (without sync) and it found an additional 4 errors - what could it be?

 

attached diagnostics

kenny-diagnostics-20240204-0647.zip

[JorgeB]

Run another check to see if it finds the same errors, you also need to check filesystem on disk3, run it without -n

[itimpi]

55 minutes ago, flixxx said:

Monthly parity check this month (1st of every month) had thousands of errors it corrected.

We normally recommend that scheduled checks are set non-correcting so that hardware playing up (that you have not yet noticed) does not end up corrupting parity.

[flixxx]

13 minutes ago, JorgeB said:

Run another check to see if it finds the same errors, you also need to check filesystem on disk3, run it without -n

 

I will run another check. 

The last time i checked the filesystem it made a huge mess of my array - bunch of files got lost, etc.... How can I ensure i don't lose anything?

 

6 minutes ago, itimpi said:

We normally recommend that scheduled checks are set non-correcting so that hardware playing up (that you have not yet noticed) does not end up corrupting parity.

 

Ok, i can certainly do that after i fix this issue

[JorgeB]

9 minutes ago, flixxx said:

How can I ensure i don't lose anything?

You can't, but most times there's no data loss, though it will depend on how serious the corruption is.

[flixxx]

11 hours ago, JorgeB said:

You can't, but most times there's no data loss, though it will depend on how serious the corruption is.

I ran a second parity check and once again it has thousands of errors.

 

I ran a filesystem check (with the -n), and then without the -n and the following was returned (with -n):

 

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - 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
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

 

 

I am running another parity check now, here is the latest diagnostics

kenny-diagnostics-20240204-1954.zip

Edited February 5 by flixxx

[trurl]

This is probably going to turn out to be bad RAM

 

Have you done memtest?

 

[flixxx]

17 hours ago, trurl said:

This is probably going to turn out to be bad RAM

 

Have you done memtest?

 

 

I have not, i will try that the moment the parity ends.

I do have a silly issue, since i run this headless.

The last time i plugged my monitor in, it works when it's booted up, but during boot up (BIOS, POST, etc...) the screen doesn't work so i never see the menu to run memtest.

I never bothered to try to fix it - any recommendation on what to look for?

[trurl]

Get memtest86.com onto another flash drive to boot from.