💾 Archived View for fuwn.me › blog › the_daily › nvme_troubles_part_1 captured on 2024-08-31 at 12:41:28. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

https://ruu.neocities.org/images/animeHeader.gif

NVMe Troubles Part 1.

Author: Fuwn

Created: 2024. 06. 17.

Last Modified: 2024. 06. 19.

NVMe Troubles Part 1.

This is the second time my primary NVMe drive has failed on me in some way in the past couple of months. I’m going to go ahead and dump this here on AniList, because it was the first page that was open on my iPad.

I wanted to create a temporary partition where I would install NixOS, just for fun to see if I would make the switch from Arch. During the resize, I was met with an error that I had inode discrepancies for a file and a folder. Of course, this was what I assumed to be related to source controlled temporary blob storage caches. I honestly should’ve been expecting this, as I have seen a ton of Btrfs related source control issues regarding inode discrepancies, especially with git and Chromium’s messy file system dumps.

Anyway, I spent probably a good 3–4 hours trying to fix this inode discrepancy, but I was getting nowhere. Eventually. I had the smart idea to run a SMART test, but this literally froze my system and eventually led to me completely turning off my system. SMART *shouldn’t* be problematic if prematurely terminating any processes, so I went ahead and did it.

Long story short, my drive was nuked … or at least I thought.

I could not boot into anything. Nothing would work. Between this phrase and the following paragraph, I was checking every possible forum, video, and thread, and they were all dead ends. I started to search for drive cloning methods, and I was a few clicks away from purchasing a new NVMe along with an M.2 drive cloning rig. I was even close to resorting to data recovery services if I so had to.

The first thing I tried was my GParted "LiveCD" USB drive, and this should always be anyone’s go to anyway. Well, GParted would not even boot. I don’t actually know why this was the case, even now, but something about the Wi-Fi drivers on their Debian release wasn’t working. I don’t even use Wi-Fi in the first place, and this shouldn’t be coming from my NVMe situation, since this is a LiveCD. After some trial and error, I realised that loading the environment into RAM got it to boot. GParted could not even see my NVMe, after all of that.

I backed out to the BIOS, and the BIOS couldn’t see my NVMe a bit. Eventually, after a series of power cycling and leaving the NVMe to rest a few minutes, (this probably didn’t help) I was able to get the BIOS to recognise the drive. I tried to run a self-test, but that self-test failed every single time.

Now, knowing that the NVMe is still visible to the motherboard, I booted back into GParted, but now, even my RAM trick wasn’t working. This too, after a few power cycles, was solved and able to boot. I’m not sure why.

As I make this post, I was successfully able to mount the supposedly "failed self-test" ridden drive, and I am able to see the entirety of my root file system.

What did I learn? I’m never choosing Btrfs again … *maybe*. In theory, it's great, but in practice it seems to lack stability in seemingly simple cases like this. (?) I think I'll go with XFS for NixOS, so I can stay on the edge, but Ext4's stability is appealing, and I've used Ext4 for a great deal of other devices and servers before in confidence. I still look at Btrfs with hope, but I just can't look at it with the same kind of hope after this nightmare scenario. I’ll also purchase one or two extra NVMes just in case, and perform regular full-disk backups. And I now want to switch to NixOS more than ever just so I can get rid of this broken Btrfs partitioned file system.

https://media1.tenor.com/m/2eFcSj58UhwAAAAC/head-bang-frustrated.gif