Upgraded To 6.9 & My Cache Drive is Not Mountable

[helpermonkey]

I first noticed the problem because docker wasn't started - i then couldn't turn it on and finally I arrived at my main page and the cache drive won't mount.

 

i have tried to check the disk filesystems but the array needs to be started. when the array is up (in or out of maintenance mode), none of the options are available to me.

 

Here some of my log from my cache drive:

Mar 2 10:49:52 Buddha kernel: ata3: SATA max UDMA/133 abar m2048@0xf7e3a000 port 0xf7e3a200 irq 27
Mar 2 10:49:52 Buddha kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 2 10:49:52 Buddha kernel: ata3.00: supports DRM functions and may not be fully accessible
Mar 2 10:49:52 Buddha kernel: ata3.00: ATA-11: Samsung SSD 860 EVO 1TB, S5B3NMFNA09237W, RVT04B6Q, max UDMA/133
Mar 2 10:49:52 Buddha kernel: ata3.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 32), AA
Mar 2 10:49:52 Buddha kernel: ata3.00: supports DRM functions and may not be fully accessible
Mar 2 10:49:52 Buddha kernel: ata3.00: configured for UDMA/133
Mar 2 10:49:52 Buddha kernel: ata3.00: Enabling discard_zeroes_data
Mar 2 10:49:52 Buddha kernel: sd 3:0:0:0: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
Mar 2 10:49:52 Buddha kernel: sd 3:0:0:0: [sde] Write Protect is off
Mar 2 10:49:52 Buddha kernel: sd 3:0:0:0: [sde] Mode Sense: 00 3a 00 00
Mar 2 10:49:52 Buddha kernel: sd 3:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar 2 10:49:52 Buddha kernel: sde: sde1
Mar 2 10:49:52 Buddha kernel: ata3.00: Enabling discard_zeroes_data
Mar 2 10:49:52 Buddha kernel: sd 3:0:0:0: [sde] Attached SCSI disk
Mar 2 10:50:22 Buddha emhttpd: Samsung_SSD_860_EVO_1TB_S5B3NMFNA09237W (sde) 512 1953525168
Mar 2 10:50:22 Buddha emhttpd: import 30 cache device: (sde) Samsung_SSD_860_EVO_1TB_S5B3NMFNA09237W
Mar 2 10:50:22 Buddha emhttpd: read SMART /dev/sde
Mar 2 10:50:29 Buddha emhttpd: shcmd (67): mount -t btrfs -o noatime,space_cache=v2 /dev/sde1 /mnt/cache
Mar 2 10:50:29 Buddha root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sde1, missing codepage or helper program, or other error.
Mar 2 12:57:31 Buddha emhttpd: read SMART /dev/sde
Mar 2 12:59:37 Buddha emhttpd: read SMART /dev/sde
Mar 2 13:00:05 Buddha emhttpd: shcmd (507): mount -t btrfs -o noatime,space_cache=v2 /dev/sde1 /mnt/cache
Mar 2 13:00:05 Buddha root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sde1, missing codepage or helper program, or other error.
Mar 2 13:00:30 Buddha emhttpd: read SMART /dev/sde
Mar 2 13:00:51 Buddha ool www[2874]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_check 'start' '/dev/sde1' 'Samsung_SSD_860_EVO_1TB_S5B3NMFNA09237W' '--readonly'
Mar 2 13:02:02 Buddha emhttpd: read SMART /dev/sde
Mar 2 13:02:50 Buddha emhttpd: shcmd (705): mount -t btrfs -o noatime,space_cache=v2 /dev/sde1 /mnt/cache
Mar 2 13:02:50 Buddha root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sde1, missing codepage or helper program, or other error.

 

When I unassign the drive - i am unable to hit mount (but it still appears in the pool drop down).

 

I do have a backup but wondering if i just preclear the drive and start over again - will Unraid rebuild that drive like it does data drives?

[JorgeB]

Please post the diagnostics: Tools -> Diagnostics

[helpermonkey]

5 hours ago, JorgeB said:

Please post the diagnostics: Tools -> Diagnostics

here ya go

buddha-diagnostics-20210303-0950.zip

[trurl]

13 hours ago, helpermonkey said:

I do have a backup but wondering if i just preclear the drive and start over again - will Unraid rebuild that drive like it does data drives?

Pool devices aren't protected by parity and since there was only one disk in the pool it had no redundancy. So it can't be rebuilt.

 

Preclear is not recommended on SSDs and in fact totally unnecessary on any disk except for testing purposes.

 

[JorgeB]

No valid btrfs filesystem is being detected on the cache device, assuming you are sure the filesystem was btrfs it was wiped or similar, best to restore from backups.

[helpermonkey]

4 minutes ago, trurl said:

Pool devices aren't protected by parity and since there was only one disk in the pool it had no redundancy. So it can't be rebuilt.

 

Preclear is not recommended on SSDs and in fact totally unnecessary on any disk except for testing purposes.

 

i figured that would be the case - thanks for confirming. Standing by for next steps.

[helpermonkey]

Just now, JorgeB said:

No valid btrfs filesystem is being detected on the cache device, assuming you are sure the filesystem was btrfs it was wiped or similar, best to restore from backups.

yeah - i didn't have it set as BTRFS .... so since i've never restored like this - what's the best guide to follow?

[trurl]

5 minutes ago, helpermonkey said:

i didn't have it set as BTRFS

Do you have any reason to think it wasn't btrfs?

[JorgeB]

7 minutes ago, helpermonkey said:

i didn't have it set as BTRFS .

If you're not sure, with the array stopped, click on cache and set fs to auto, then start array and post new diags.

[helpermonkey]

3 minutes ago, trurl said:

Do you have any reason to think it wasn't btrfs?

good question - not really - i just can't ever remember having set it up like that .... while this drive is technically on the newer side of things - i upgraded from the previous one which i setup years ago and honestly don't ever remember BTRFS - but it's not like i was looking keenly at that and the mind is a mysterious thing.

2 minutes ago, JorgeB said:

If you're not sure, with the array stopped, click on cache and set fs to auto, then start array and post new diags.

See attached 🙂

buddha-diagnostics-20210303-1030.zip

[JorgeB]

Yep, of the 3 possible file systems Unraid uses there's no valid one on that device:

 

Mar  3 10:30:30 Buddha emhttpd: shcmd (68610): mkdir -p /mnt/cache
Mar  3 10:30:30 Buddha emhttpd: shcmd (68611): blkid -t TYPE='xfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68611): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: shcmd (68612): blkid -t TYPE='btrfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68612): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: shcmd (68613): blkid -t TYPE='reiserfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68613): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: /mnt/cache mount error: No file system

 

You need to restore from backups.

[helpermonkey]

1 minute ago, JorgeB said:

Yep, of the 3 possible file systems Unraid uses there's no valid one on that device:

 

Mar  3 10:30:30 Buddha emhttpd: shcmd (68610): mkdir -p /mnt/cache
Mar  3 10:30:30 Buddha emhttpd: shcmd (68611): blkid -t TYPE='xfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68611): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: shcmd (68612): blkid -t TYPE='btrfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68612): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: shcmd (68613): blkid -t TYPE='reiserfs' /dev/sdd1 &> /dev/null
Mar  3 10:30:30 Buddha emhttpd: shcmd (68613): exit status: 2
Mar  3 10:30:30 Buddha emhttpd: /mnt/cache mount error: No file system

 

You need to restore from backups.

so i'm slightly curious as to how the upgrade deleted the filesystem but that being said - what's the best way to do that given that the device is showing as unmountable?

[JorgeB]

4 minutes ago, helpermonkey said:

so i'm slightly curious as to how the upgrade deleted the filesystem but that being said

Unrelated.

 

4 minutes ago, helpermonkey said:

what's the best way to do that given that the device is showing as unmountable?

Format then restore data from backups.

[helpermonkey]

1 minute ago, JorgeB said:

Unrelated.

 

Format then restore data from backups.

interesting - so before the upgrade - everything worked and was fine - after the upgrade - the filesystem was gone. If i can provide anything that might help the devs team let me know. Nothing else was done other than the upgrade.

[JorgeB]

More likely the result of the reboot, upgrade doesn't touch any filesystem.

[helpermonkey]

26 minutes ago, JorgeB said:

More likely the result of the reboot, upgrade doesn't touch any filesystem.

Okay - good to learn- so what would have happened to cause the files to be deleted as after the "upgrade" it says to reboot to take effect - i always considered those part of the "upgrade".

[trurl]

The flash drive doesn't contain the OS, it contains the archives of the OS. These archives are unpacked fresh from the boot flash into RAM at each boot, then the OS runs completely in RAM. Think of it as firmware but easier to work with.

 

When you upgrade, those original archives are copied to the 'previous' folder on the flash drive, and the new archives from the download are written to flash where they will be used at the next boot. SInce the OS is in RAM, the new OS isn't loaded until reboot.

[helpermonkey]

36 minutes ago, JorgeB said:

More likely the result of the reboot, upgrade doesn't touch any filesystem.

Okay so i've formatted the drive and i see the docker.img file on the cache drive ... can i just hit restore here?

 

here are my shares as well.

Edited March 3, 2021 by helpermonkey

[trurl]

After restoring your appdata you will have to recreate docker.img and reinstall each of your dockers using the Previous Apps feature on the Apps page. Be sure to use the Previous Apps feature, if you try to just install them without using that feature you will be starting with a fresh docker template.

 

As explained in your screenshot.

[fmjets11]

It is interesting that when I did the upgrade something similar happened to me....my cache drives were both unmourned and taken out of the array but data wasn’t lost. Maybe 6.9 isn’t stable?


Sent from my iPhone using Tapatalk

[JorgeB]

12 minutes ago, fmjets11 said:

It is interesting that when I did the upgrade something similar happened to me....my cache drives were both unmourned and taken out of the array but data wasn’t lost. Maybe 6.9 isn’t stable?

No similar at all, yours were just unassigned, not wiped, that's very different thing.

[helpermonkey]

3 minutes ago, JorgeB said:

No similar at all, yours were just unassigned, not wiped, that's very different thing.

Are you sure? After i restarted - the first thing i did was launch plex. I got an error so i logged in - went to the dockers page - saw the dockers were turned off. I went to the settings to turn it back on and wasn't able to do it. I went to the main page and saw the cache drive was listed in the correct place but with the Unmountable error message. So if it wasn't wiped - what exactly happened where my server was working fine - i hit upgrade - then restart - and it was no longer functioning properly.

[JorgeB]

1 hour ago, helpermonkey said:

Are you sure?

Yes, you can see his thread, he just re-assigned the devices and the pool came back, no data was lost.

[Aurial]

Just to add, I have the exact same drive as my cache and it's also unmountable when the server came back up from reboot after upgrading.

[helpermonkey]

1 hour ago, JorgeB said:

Yes, you can see his thread, he just re-assigned the devices and the pool came back, no data was lost.

oh - whoops - i didnt realize someone else had joined in. i thought you were talking to me ;-). I'm all good now back up and running - thanks for your help.