💾 Archived View for fuwn.me › blog › the_daily › nvme_troubles_part_3 captured on 2024-09-29 at 00:47:46. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
https://ruu.neocities.org/images/animeHeader.gif
Author: Fuwn
Created: 2024. 09. 03.
Last Modified: 2024. 09. 03.
Previously on The Daily: NVMe Troubles Part 2.
This may not be the crash and burn scenario you were expecting after this three part series, but you might be surprised to learn that the NVMe drive is still up and running months later after some "questionable treatment".
I'll also mention that the events of this post are about two months old, but the process wasn't too complicated that I'd forget the details. You'd also expect that I would have gotten around to finally fixing the Btrfs partition just before I wanted to install the long awaited NixOS, but, no, I actually just had a spurt of motivation sometime in the AM.
At this point in my Btrfs filesystem saga, I had tried all but cloning-wiping-restoring my partition and/or NVMe and `btrfs check --repair`. I can't recall the exact message, although, with the amount of times I've seen it at this point, I should, but the message that `btrfs check --repair` usually gives is something along the lines of "Only run this command if you are OK with losing your data or a Btrfs developer tells you to."—I think. I didn't want to deal with the cloning BS, so I'll bite the bullet and go with Btrfs's obscure repair functionality that **absolutely no one** advises using.
To prepare, I wanted to save at least some of my data. I don't actually care about any directories on my system apart from my home directory and some `/etc/` files, so I'll back them up accordingly.
During my backup endeavours, I tried a few methods, but ultimately, I wasn't satisfied with any of the results. One method was `rsync`-ing everything, another was zipping everything into an archive, and I also tried plain copying. One annoyance was that I was cloning from a Linux filesystem to a NTFS one, which was giving me all kinds of pain with file permissions and other metadata. I also ditched `rsync` and zipping in the end, because they didn't produce the expected results in one way or another. Backing up from userland is not fun, I guess. That, and I already had sunk a few hours into the ordeal, so it just wasn't worth my time.
By this stage, I think my exact thoughts were "Screw it, `--repair` can't be that bad. It exists for a reason." I run the forsaken `btrfs check --repair` without any remorse. Maybe it was the adrenaline, but the repair felt like it had gone through almost instantly. It couldn't have been longer than around a minute or two, at the absolute most.
In these moments of post-repair bliss, I ran `btrfs check` to verify if the repair had done anything at all, and the previous errors were nowhere to be seen. I also did some digging in the mounted filesystem, and everything seemed to look and function just how I left it. Booting back into Arch also went fine, not that I couldn't before, but I was just making sure I hadn't screwed anything up again.
Functionality, I gained nothing, since the filesystem and drive still worked perfectly fine, even with the inode errors screaming at me; however, I'd now finally be able to modify the drive through GParted. If I hadn't mentioned already, GParted runs a `btrfs check` before any operations on a Btrfs partition, which is why I'd eventually need to repair the partition to continue on with my plans to install NixOS, so I spared future me the trouble.
I used my system like normal for a few weeks, after which I went on a month long holiday abroad, away from my rig, and I wasn't about to attempt to install NixOS via SSH, although, the steps to do so are documented within the NixOS installation instructions.
Spoiler alert, but I did install NixOS, and I'm currently writing this post on it. It's definitely the best Linux distribution I've used so far, and just from the short experience I've had with it, I can tell you that I can't see myself ever using anything else. I might write a post about it soon, so keep an eye out for that.
I won't go as far as to say use `btrfs check --repair`, but if a filesystem has strictly inode-related errors, I think it might be the quickest, and possibly even safest, way to fix them. I could have just gotten lucky, but I'm not one to tempt fate, so I'll just leave it at that.
"If you can't give me poetry, can't you give me poetical science?" - Ada Lovelace
Copyright (c) 2021-2024 Fuwn. All rights reserved.
Any and all opinions listed here are my own and not representative of my employers; past, present, and future.
