Array drive unmountable after smart check and party-check

[lahger]

Hello awesome community!

 

Today I was playing around with a docker container, for some reason it broke after an edit. I had some other dockers routed through it (I was editing binhex-delugeVPN) and after a 403 error when I tried to start it I took a look at the log of the container and it said a identical container-ID needed to be removed to start up the first one, so I did that with "docker rm #containerID". Then all hell broke loose.

After a reboot the docker service can't start. So I did a restore of the container with the Backup/restore Appdata plugin. Did a smart status check of the drive, without errors.

Then I did a parity-check as a just in case, then I rebooted again and now my only array drive is unmountable.. I am at a loss here and desperately need help saving my data.

 

Thanks in advance!

nas-syslog-20240303-2152.zip

[JorgeB]

Check filesystem on disk1, run it without -n.

[lahger]

1 hour ago, JorgeB said:

Check filesystem on disk1, run it without -n.

Thanks for the reply, all i get is this error:

"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."

[itimpi]

You need to run without -n and add -L

[lahger]

Ok so i got this:

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
invalid start block 2431640529 in record 22 of cnt btree block 2/1406531
invalid start block 550648526 in record 23 of cnt btree block 2/1406531
agf_freeblks 51159384, counted 51159376 in ag 2
agi unlinked bucket 3 is 1019587 in ag 1 (inode=1074761411)
sb_ifree 5850, counted 5851
sb_fdblocks 335077470, counted 340134580
        - 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
bad CRC for inode 7049496543
bad CRC for inode 7049496543, will rewrite
cleared inode 7049496543
        - 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 = 4
        - agno = 7
        - agno = 5
        - agno = 3
        - agno = 6
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 ...
disconnected inode 1074761411, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (35:914517) is ahead of log (1:2).
Format log to cycle 38.
done

Any ideas?

[itimpi]

The dtive should now mount when the array is started innNormal mode.

 

You should check whether this a Lost+Found folder on the drive - this is where the repair process would put any files/folders for which it could not find the directory entry to give them their correct name.

[lahger]

Oh thank you so much, the drive is back alive!

There is one file in the lost+found but the file is empty, the name of said file is 1074461411 if that is of any use.

[itimpi]

3 minutes ago, lahger said:

Oh thank you so much, the drive is back alive!

There is one file in the lost+found but the file is empty, the name of said file is 1074461411 if that is of any use.

The name is always something cryptic (since the directory entry cannot be found).   If it is empty you can simply delete it.

[lahger]

1 minute ago, itimpi said:

The name is always something cryptic (since the directory entry cannot be found).   If it is empty you can simply delete it.

Alright, thank you all for the help, gotta love this awesome community!

I think it is time to start following the 3-2-1 rule for my data now..