Chasing down disabled drive / CRC errors

[JorgeB]

Run it again without -n and without -L, if it didn't finish before and asks for -L again use it.

[Arcaeus]

12 minutes ago, JorgeB said:

Run it again without -n and without -L, if it didn't finish before and asks for -L again use it.

 

Ok it looks like it completed, here is the output:

root@MediaVault:~# xfs_repair -v /dev/md7
Phase 1 - find and verify superblock...
        - block cache size set to 542384 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 0 tail block 0
        - scan filesystem freespace and inode maps...
        - 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
        - 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
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Tue May 10 11:15:48 2022

Phase           Start           End             Duration
Phase 1:        05/10 11:15:48  05/10 11:15:48
Phase 2:        05/10 11:15:48  05/10 11:15:48
Phase 3:        05/10 11:15:48  05/10 11:15:48
Phase 4:        05/10 11:15:48  05/10 11:15:48
Phase 5:        05/10 11:15:48  05/10 11:15:48
Phase 6:        05/10 11:15:48  05/10 11:15:48
Phase 7:        05/10 11:15:48  05/10 11:15:48

Total run time:
done

 

What's next? Restart the array and rebuild parity?

Edited May 10, 2022 by Arcaeus

[JorgeB]

11 minutes ago, Arcaeus said:

Restart the array and rebuild parity?

Just restart the array, parity is valid.

[itimpi]

30 minutes ago, Arcaeus said:

 

Ok ran it with that flag, but my computer (not Unraid Server) crashed midway through and killed the SSH session. Is there a way to check on the progress? Maybe run the same command but with the -n flag to check?

I think that means the command probably did not complete. Running again should be OK.

[Arcaeus]

12 minutes ago, JorgeB said:

Just restart the array, parity is valid.

 

Ok array is started with disk 7 mounted now, thank you. It looks like there are a lot of files in the lost+found folder, and Main - Array also shows a lot of free space on the disk, much more than was there before. 

 

What's my next step? Do I need to go through lost+found on the drive and move files back to where they should be or will Unraid put back what was there before? Or do it from the lost+found share? I know moving files from a specific disk was not recommended on Unraid but not sure if that applies here.

Edited May 10, 2022 by Arcaeus

[JorgeB]

It's safe to move from one share to another.

[itimpi]

Just now, Arcaeus said:

What's my next step? Do I need to go through lost+found on the drive and move files back to where they should be or will Unraid put back what was there before? Or do iI know moving files from a specific disk was not recommended on Unraid but not sure if that applies here.

Files in the lost+found folder are ones where the repair process could not find the directory entry to give them their correct name (so Unraid does not know where they belong).   If you can sort them out then you can move them back to the correct share, but often they have cryptic numeric names so it is not that easy.  Recovering from backups often tends to be easiest (if you gave them). If you NEED to sort out the files in list+found then the Linux ‘file’ command can be useful in determining what type a file is (and thus it’s probable extension).