[SOLVED] "Unmountable disk present" after 6TB drive replacement and rebuild

[Kjeld]

I don't understand why the second image is there. The rebuild after placing in a new drive and with the blue icon I end up with the above images.
Disk1 was broken and replaced. It also has been written to a lot in the past 18 hours. Please advise.

[JorgeB]

A rebuilt disk will show exactly hat was on the emulated one, please post the diagnostics.

[Kjeld]

Here is the full zip [removed]

Edited September 27, 2022 by Kjeld

[JorgeB]

Check filesystem on disk1.

[Kjeld]

Phase 1 - find and verify superblock...
        - block cache size set to 612184 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
        - agno = 4
        - agno = 5
        - 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 = 3
        - agno = 2
        - agno = 4
        - agno = 5
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - 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
        - agno = 4
        - agno = 5
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Tue Sep 27 13:10:24 2022

Phase        Start        End        Duration
Phase 1:    09/27 13:07:52    09/27 13:07:55    3 seconds
Phase 2:    09/27 13:07:55    09/27 13:07:56    1 second
Phase 3:    09/27 13:07:56    09/27 13:09:44    1 minute, 48 seconds
Phase 4:    09/27 13:09:44    09/27 13:09:45    1 second
Phase 5:    09/27 13:09:45    09/27 13:10:04    19 seconds
Phase 6:    09/27 13:10:04    09/27 13:10:23    19 seconds
Phase 7:    09/27 13:10:23    09/27 13:10:23

Total run time: 2 minutes, 31 seconds
done

Does not seem to change anything.

[JorgeB]

Start the array in normal mode.

[Kjeld]

That worked! Wow, is this normal? My stress level was up there. Thanks for the quick response/support. I did lose some faith in the software.
But thanks again JorgeB!

[JorgeB]

File system corruption can happen especially after an unclean shutdown or when a disk gets disabled, it's kind of an unclean shutdown for the filesystem, but usually a filesystem check fixes it.

[trurl]

See if you have a new 'lost+found' user share where filesystem repair would have put anything it couldn't figure out.

[Kjeld]

It seems that most data on Disk1 was /video

root@void-unraid:~# ls -rtlha  /mnt/user/
total 16K
drwxrwxrwx  1 nobody users    6 Jan 12  2022 docker-store/
drwxrwxrwx  1 nobody users   20 Jan 13  2022 appdata/
drwxrwxrwx  1 nobody users   90 Jan 17  2022 isos/
drwxrwxrwx  1 nobody users   36 Jan 26  2022 vms/
drwxrwxrwx  1 nobody users    6 Feb  9  2022 domains/
drwxrwxrwx  1 nobody users  104 Sep 26 20:51 ./
drwxrwxrwx  1 nobody users   35 Sep 26 20:51 system/
drwxr-xr-x 12 root   root   240 Sep 27 13:59 ../
drwxrwxrwx  1 nobody users 8.0K Sep 27 14:14 video/
drwxrwxrwx  1 nobody users    6 Sep 28 08:45 time-machine/

No lost+found extra directory there. All looks good, thanks again.