Disk became Unmountable: Unsupported or no file system

[Nik.V]

Yesterday I had some trouble increasing the RAM of my only VM and I had to restart the server because applying the VM config changes did not resolve and the changes did not apply when I force exited the config edit page. After the restart I was able to increase the VM RAM amount and save the changes succussfully. At some point after that I got an alert from Fix Common Problems that disk1 was not defined. I ignored the alert because I did not notice any other problems. But today I see that I have folders and data missing and saw that indeed there is a problem with Disk1: Unmountable: Unsupported or no file system.

 

I saw in other topics that the command 

xfs_repair

is used, however I am not sure if the problem is the same, thus I am attaching diagnostics.

tnvnas-diagnostics-20231102-2352.zip

[trurl]

28 minutes ago, Nik.V said:

alert from Fix Common Problems that disk1 was not defined. I ignored the alert

Seems like a pretty serious thing to ignore.

 

Check filesystem on disk1

 

[Nik.V]

I did a filesystem Check on disk1. Here is the result:

Phase 1 - find and verify superblock...
        - block cache size set to 2274088 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 880119 tail block 879485
ALERT: The filesystem has valuable metadata changes in a log which is being
ignored because the -n option was used.  Expect spurious inconsistencies
which may be resolved by first mounting the filesystem to replay the log.
        - scan filesystem freespace and inode maps...
invalid start block 2429932840 in record 208 of cnt btree block 0/6163624
out-of-order cnt btree record 209 (63702579 1507) block 0/6163624
invalid start block 550172752 in record 223 of cnt btree block 0/6163624
agf_freeblks 58796407, counted 58793345 in ag 0
agi unlinked bucket 1 is 588393473 in ag 0 (inode=588393473)
agi unlinked bucket 2 is 588393474 in ag 0 (inode=588393474)
agi unlinked bucket 3 is 588393475 in ag 0 (inode=588393475)
agi unlinked bucket 4 is 588393476 in ag 0 (inode=588393476)
agi unlinked bucket 6 is 588393478 in ag 0 (inode=588393478)
agi unlinked bucket 7 is 588393479 in ag 0 (inode=588393479)
agi unlinked bucket 8 is 588393480 in ag 0 (inode=588393480)
agi unlinked bucket 27 is 588393499 in ag 0 (inode=588393499)
agi unlinked bucket 28 is 588393500 in ag 0 (inode=588393500)
agi unlinked bucket 48 is 588343728 in ag 0 (inode=588343728)
agi unlinked bucket 50 is 588343730 in ag 0 (inode=588343730)
agi unlinked bucket 51 is 588343731 in ag 0 (inode=588343731)
agi unlinked bucket 52 is 588343732 in ag 0 (inode=588343732)
agi unlinked bucket 53 is 588343733 in ag 0 (inode=588343733)
agi unlinked bucket 55 is 588343735 in ag 0 (inode=588343735)
agi unlinked bucket 57 is 588343737 in ag 0 (inode=588343737)
agi unlinked bucket 58 is 588343738 in ag 0 (inode=588343738)
agi unlinked bucket 60 is 588343740 in ag 0 (inode=588343740)
agi unlinked bucket 61 is 588343741 in ag 0 (inode=588343741)
agi unlinked bucket 62 is 588343742 in ag 0 (inode=588343742)
agi unlinked bucket 63 is 588343743 in ag 0 (inode=588343743)
sb_icount 282176, counted 281792
sb_ifree 112801, counted 113070
sb_fdblocks 97857219, counted 104712437
        - 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...
free space (0,62708128-62709628) only seen by one free space btree
free space (0,65460880-65462440) only seen by one free space btree
        - check for inodes claiming duplicate blocks...
        - agno = 2
        - agno = 0
        - agno = 3
        - agno = 1
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 588343728, would move to lost+found
disconnected inode 588343730, would move to lost+found
disconnected inode 588343731, would move to lost+found
disconnected inode 588343732, would move to lost+found
disconnected inode 588343733, would move to lost+found
disconnected inode 588343735, would move to lost+found
disconnected inode 588343737, would move to lost+found
disconnected inode 588343738, would move to lost+found
disconnected inode 588343740, would move to lost+found
disconnected inode 588343741, would move to lost+found
disconnected inode 588343742, would move to lost+found
disconnected inode 588343743, would move to lost+found
disconnected inode 588393473, would move to lost+found
disconnected inode 588393474, would move to lost+found
disconnected inode 588393475, would move to lost+found
disconnected inode 588393476, would move to lost+found
disconnected inode 588393478, would move to lost+found
disconnected inode 588393479, would move to lost+found
disconnected inode 588393480, would move to lost+found
disconnected inode 588393499, would move to lost+found
disconnected inode 588393500, would move to lost+found
Phase 7 - verify link counts...
would have reset inode 588343728 nlinks from 0 to 1
would have reset inode 588343730 nlinks from 0 to 1
would have reset inode 588343731 nlinks from 0 to 1
would have reset inode 588343732 nlinks from 0 to 1
would have reset inode 588343733 nlinks from 0 to 1
would have reset inode 588343735 nlinks from 0 to 1
would have reset inode 588343737 nlinks from 0 to 1
would have reset inode 588343738 nlinks from 0 to 1
would have reset inode 588343740 nlinks from 0 to 1
would have reset inode 588343741 nlinks from 0 to 1
would have reset inode 588343742 nlinks from 0 to 1
would have reset inode 588343743 nlinks from 0 to 1
would have reset inode 588393473 nlinks from 0 to 1
would have reset inode 588393474 nlinks from 0 to 1
would have reset inode 588393475 nlinks from 0 to 1
would have reset inode 588393476 nlinks from 0 to 1
would have reset inode 588393478 nlinks from 0 to 1
would have reset inode 588393479 nlinks from 0 to 1
would have reset inode 588393480 nlinks from 0 to 1
would have reset inode 588393499 nlinks from 0 to 1
would have reset inode 588393500 nlinks from 0 to 1
No modify flag set, skipping filesystem flush and exiting.

        XFS_REPAIR Summary    Fri Nov  3 22:50:18 2023

Phase		Start		End		Duration
Phase 1:	11/03 22:49:36	11/03 22:49:36
Phase 2:	11/03 22:49:36	11/03 22:49:37	1 second
Phase 3:	11/03 22:49:37	11/03 22:49:59	22 seconds
Phase 4:	11/03 22:49:59	11/03 22:50:00	1 second
Phase 5:	Skipped
Phase 6:	11/03 22:50:00	11/03 22:50:18	18 seconds
Phase 7:	11/03 22:50:18	11/03 22:50:18

Total run time: 42 seconds

 

Should I run the Check operation with only -v option?

[Nik.V]

I actually tried starting the array back up in normal mode after doing the filesystem Check (did the filesystem Check in maintenance mode), but the drive was still Unmountable.

[itimpi]

1 minute ago, Nik.V said:

I actually tried starting the array back up in normal mode after doing the filesystem Check (did the filesystem Check in maintenance mode), but the drive was still Unmountable.

Did you run without the -n option so something actually got fixed?    The output you posted was a read-only check .

[Nik.V]

I have not. Will run it now without -n option.

[Nik.V]

Ran the Check witout -n and got this:

Phase 1 - find and verify superblock...
        - block cache size set to 2274088 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 880119 tail block 879485
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.

Should I start the array first before using -L option?

[Nik.V]

Ok, I started the array in normal mode but still Unmountable. After that I ran with -L option and it fixed it. Now the disk is working

[trurl]

Be sure to check your lost+found share for things repair couldn't figure out