Hello, basically what the title says, after an unexpected reboot, one disk appears with the message "Unmountable: Unsuported or no file system", but the drive is not have the "contents emulated" warning.

I tried "xfs_repair -v /dev/nvme1n1" but after a while it does not detect secondary superblock.

At the same time, all my dockers dissapeared.

Is there a way to recover it or should i go format it and go to the backup?

My backup is a full dump of the array as-is, so I will have to manually check what files where in that drive specifically, i would like to avoid it if possible.

Thanks!
 

server1a-diagnostics-20231025-0115.zip

Have you tried running the repair from the GUI so you get the correct device name?

8 hours ago, SHALcL said:

"xfs_repair -v /dev/nvme1n1"

Assuming the device is correct It should be /dev/nvme1n1p1

16 minutes ago, JorgeB said:

Assuming the device is correct It should be /dev/nvme1n1p1

Yeah, its the right drive.
 

But I used the wrong path. With the right path get this:

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

 

Edited October 25, 20232 yr by SHALcL

7 hours ago, itimpi said:

Have you tried running the repair from the GUI so you get the correct device name?

I dont see any repair option on the array or the disk sections.

Use -L

1 hour ago, SHALcL said:

I dont see any repair option on the array or the disk sections.

If you click on the drive on the Main tab then there is an option for checking or repairing as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

Just now, JorgeB said:

Use -L

I got this:
 

Sorry, could not find valid secondary superblock
Exiting now.

 

3 minutes ago, itimpi said:

If you click on the drive on the Main tab then there is an option for checking or repairing as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

Oh, you mean the check fylesystem thing. AFAIK is he same as "xfs_repair".

That suggest you used the wrong device again, use:

 

xfs_repair -L /dev/nvme1n1p1

 

1 minute ago, SHALcL said:

Oh, you mean the check fylesystem thing. AFAIK is he same as "xfs_repair".

Yes it is - but doing it via the GUI ensures the correct device name is used.   The name can vary according to the Unraid release being used and whether you are using encryption or not.    The GUI automatically gets this right.

3 minutes ago, JorgeB said:

That suggest you used the wrong device again, use:

 

xfs_repair -L /dev/nvme1n1p1

 

Goddammit, why do i trust autocomplete?

That fixed it, thank you very much!

QQ: Why where the contents not emulated in that scenario?

I had a drive fail before and it was emulated, allowing all the programs to work with some performance degradation.

1 minute ago, SHALcL said:

QQ: Why where the contents not emulated in that scenario?

I had a drive fail before and it was emulated, allowing all the programs to work with some performance degradation.

 

Emulation works at the physical disk sector level and has no idea of file systems.   It thus protects against a disk physically failing.   In this case the problem is at the file system level and needs fixing using software that is file system aware.

I see

Thanks!