Cach Drive Unmountable after Upgrade


Recommended Posts

Since I ran the reboot to upgrade to 6.9.1 my cache drive is unmountable.  I read in a few posts that sounded simmilar making sure that they are running the same Filesystem would be a good first step.  Still no dice.  The real problem is it seems to have defaulted my unifi controller server.... I'd really like to get that back, aaaaand run it off cache in the future.

 

Any suggestions?

IMG_0403.jpeg

Screen Shot 2021-04-01 at 12.41.41 PM.png

Link to comment

Do you know what the filesystem is supposed to be? Your screenshot shows XFS but your syslog seems to indicate it decided btrfs instead and failed to mount:

Apr  1 12:24:52 ICE-METAL emhttpd: shcmd (52): mkdir -p /mnt/cache
Apr  1 12:24:52 ICE-METAL emhttpd: shcmd (53): blkid -t TYPE='xfs' /dev/nvme1n1p1 &> /dev/null
Apr  1 12:24:52 ICE-METAL emhttpd: shcmd (53): exit status: 2
Apr  1 12:24:52 ICE-METAL emhttpd: shcmd (54): blkid -t TYPE='btrfs' /dev/nvme1n1p1 &> /dev/null
Apr  1 12:24:52 ICE-METAL emhttpd: shcmd (55): mount -t btrfs -o noatime,space_cache=v2 /dev/nvme1n1p1 /mnt/cache
Apr  1 12:24:52 ICE-METAL kernel: BTRFS info (device nvme1n1p1): enabling free space tree
Apr  1 12:24:52 ICE-METAL kernel: BTRFS info (device nvme1n1p1): using free space tree
Apr  1 12:24:52 ICE-METAL kernel: BTRFS info (device nvme1n1p1): has skinny extents
Apr  1 12:24:52 ICE-METAL kernel: BTRFS info (device nvme1n1p1): enabling ssd optimizations
Apr  1 12:24:52 ICE-METAL kernel: BTRFS info (device nvme1n1p1): creating free space tree
Apr  1 12:24:53 ICE-METAL kernel: BTRFS critical (device nvme1n1p1): corrupt leaf: block=319438848 slot=6 extent bytenr=525130129408 len=65536 invalid generation, have 18446612817294090488 expect (0, 8296690]
Apr  1 12:24:53 ICE-METAL kernel: BTRFS error (device nvme1n1p1): block=319438848 read time tree block corruption detected
Apr  1 12:24:53 ICE-METAL kernel: BTRFS: error (device nvme1n1p1) in btrfs_create_free_space_tree:1189: errno=-5 IO failure
Apr  1 12:24:53 ICE-METAL kernel: BTRFS warning (device nvme1n1p1): failed to create free space tree: -5
Apr  1 12:24:53 ICE-METAL kernel: BTRFS error (device nvme1n1p1): commit super ret -30
Apr  1 12:24:53 ICE-METAL root: mount: /mnt/cache: can't read superblock on /dev/nvme1n1p1.
Apr  1 12:24:53 ICE-METAL kernel: BTRFS error (device nvme1n1p1): open_ctree failed
Apr  1 12:24:53 ICE-METAL emhttpd: shcmd (55): exit status: 32
Apr  1 12:24:53 ICE-METAL emhttpd: /mnt/cache mount error: not mounted
Apr  1 12:24:53 ICE-METAL emhttpd: shcmd (56): umount /mnt/cache
Apr  1 12:24:53 ICE-METAL root: umount: /mnt/cache: not mounted.
Apr  1 12:24:53 ICE-METAL emhttpd: shcmd (56): exit status: 32
Apr  1 12:24:53 ICE-METAL emhttpd: shcmd (57): rmdir /mnt/cache

 

Link to comment

I've read elsewhere on the forum that the newer kernel is less tolerant of BTRFS corruption, so possibly the best way forward would be to temporarily roll back the OS using the Tools, Update OS, Unraid previous, Restore function.

 

If that gets your cache mounted, you should immediately do a backup in preparation for restoring it after a clean format of the cache drive.

Link to comment
15 minutes ago, MendoRugger said:

YES!!!  You're the man!!  It's up, dockers are working and mover is running!!!  Going to swap out that SSD with one I had already planned on putting in anyway.

Mover can't move open files, so if the docker and vm service are enabled, files will be left on the cache. You need to make sure not just that the containers are stopped, but the entire docker service is disabled so the mover can complete properly.

Link to comment
4 hours ago, jonathanm said:

the newer kernel is less tolerant of BTRFS corruption

 

Looking at that from a slightly different angle, the older kernel was perhaps less able to detect existing corruption, which remained hidden until the upgrade revealed it. I think rolling back is only a temporary measure to give the opportunity to rescue the user's data. Ultimately, the only way forward is to fix the corruption which, in btrfs's case, usually means re-formatting.

 

Link to comment
On 4/2/2021 at 2:13 AM, John_M said:

Looking at that from a slightly different angle, the older kernel was perhaps less able to detect existing corruption, which remained hidden until the upgrade revealed it.

Correct, newer kernel can detect previously undetected corruption, user should downgrade, backup cache and the upgrade and re-format.

Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.