XFS SSD CACHE DRIVE SUDDEN ERROR - "UNMOUNTABLE - UNSUPPORTED OR NO FILESYSTEM"

[DaveHavok]

Hey gang - Happy Holidays!

My Cache SSD drive just popped this error and it persists after a reboot and shutdown - "UNMOUNTABLE - UNSUPPORTED OR NO FILESYSTEM"

-SMART check comes back OK with no issues

-In Maintenance Mode - I'm unable to run XFS-Repair under the Cache Settings tab for the drive (see error below)

/dev/sdq1: No such file or directory

fatal error -- couldn't initialize XFS library

 

- Looking at the bottom of the syslog.txt - I see this error

Nov 29 20:38:32 ServerName ool www[5102]: /usr/local/emhttp/plugins/dynamix/scripts/xfs_check 'start' '/dev/sdq1' 'LITEONIT_LMT-256L9M-11_MSATA_256GB_TW0N42H7550854713641' '-n'
Nov 29 20:40:44 ServerName kernel: /dev/sdq1: Can't open blockdev

 

Please help and thank you!
 

 

 

origaminet-diagnostics-20231129-2051.zip

[DaveHavok]

UPDATE:

I found for following when reviewing the SYSLOG
 

Nov 29 20:16:05 ServerName emhttpd: mounting /mnt/cache
Nov 29 20:16:05 ServerName emhttpd: shcmd (200): mkdir -p /mnt/cache
Nov 29 20:16:05 ServerName emhttpd: shcmd (201): mount -t xfs -o noatime,nouuid /dev/sdq1 /mnt/cache
Nov 29 20:16:05 ServerName kernel: /dev/sdq1: Can't open blockdev
Nov 29 20:16:05 ServerName root: mount: /mnt/cache: special device /dev/sdq1 does not exist.
Nov 29 20:16:05 ServerName root:        dmesg(1) may have more information after failed mount system call.
Nov 29 20:16:05 ServerName emhttpd: shcmd (201): exit status: 32
Nov 29 20:16:05 ServerName emhttpd: /mnt/cache mount error: Unsupported or no file system

 

running dmesg - I see this jump out at me:
 

/dev/sdq1: Can't open blockdev
[ 3279.911117] mdcmd (36): nocheck cancel

 

Edited November 30, 2023 by DaveHavok

[DaveHavok]

UPDATE 2:

Running the following terminal command:  xfs_repair -n /dev/sdq

Outputs this:

 Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
.....<> .....
found candidate secondary superblock
unable to verify superblock continuing...
.....<> .....

It just keeps going and going....


Stopping it and running: fdisk -l /dev/sdq
 

fdisk -l /dev/sdq
Disk /dev/sdq: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: LITEONIT LMT-256
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

 

Not sure what to do now as this looks like there is no partition table here... hmmm

 

When I try and mount the cache drive - I get his error:

/dev# mount dev/sdq /mnt/tmp
mount: /mnt/tmp: special device dev/sdq does not exist.
       dmesg(1) may have more information after failed mount system call.

 

Edited November 30, 2023 by DaveHavok

[DaveHavok]

Looking in my /dev folder - I do not have an sdq1 like all the other drives.... I'm guessing that's a bad thing?

 

[JorgeB]

Post the output of:

fdisk -l /dev/sdq

 

[DaveHavok]

Thanks @JorgeB!

Here's the output:

 

fdisk -l /dev/sdq
Disk /dev/sdq: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: LITEONIT LMT-256
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

I'm not seeing a partition there  
Unfortunately - I need to rescue the appdata folder off of this drive and like an idiot - I'm just now finding out that my Cache Drive folder was not being backup.

So anything I can do to try and recover this drive data would be appreciated! 

[JorgeB]

34 minutes ago, DaveHavok said:

I'm not seeing a partition there  

Yep, you can try testdisk or a similar utility to see if it can recover the old partition, assuming the device was not fully trimmed.

[DaveHavok]

@JorgeB - Yeah, I was afraid of that. Curious what could have caused the partition loss. The SMART check comes back OK and there were no recent changes or power outages. I suspect that either the RAM or NVMe SSD (Cache Drive) might be reaching early hardware failure.

Some good news though, Future me had the critical data stashed away in several other areas and I'll be able to use that to rebuild my Docker images / AppData with low down time.
This time I'll verify that the AppData Backup app is installed and running - not sure why I removed it.

The other good news is this will make building my new unRAID server easier since I don't have to deal with moving the AppData from the old Cache drive. 
Just setup a fresh instance on the new Cache drive and use my stashed data to reconstruct the new AppData.

Thanks for the second set of eyes on this and I feel better having verified my critical data being safe.

Cheers and Happy Holidays.