aboutsummaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
authorFuwn <[email protected]>2024-06-19 03:23:36 -0700
committerFuwn <[email protected]>2024-06-19 03:23:39 -0700
commitfe9bae54ad0de4e88834730bbb26900534e3ae98 (patch)
treef40b129012599eea9bea58e618fd7d6eca7da2bf /content
parentfeat(the_daily): update nvme troubles #2 (diff)
downloadlocus-fe9bae54ad0de4e88834730bbb26900534e3ae98.tar.xz
locus-fe9bae54ad0de4e88834730bbb26900534e3ae98.zip
feat(the_daily): add reference to part 2. of nvme troubles in part 1.
Diffstat (limited to 'content')
-rw-r--r--content/blogs/the_daily/nvme_troubles_part_1.gmi6
1 files changed, 6 insertions, 0 deletions
diff --git a/content/blogs/the_daily/nvme_troubles_part_1.gmi b/content/blogs/the_daily/nvme_troubles_part_1.gmi
index 1c43448..35eb19e 100644
--- a/content/blogs/the_daily/nvme_troubles_part_1.gmi
+++ b/content/blogs/the_daily/nvme_troubles_part_1.gmi
@@ -21,3 +21,9 @@ As I make this post, I was successfully able to mount the supposedly "failed sel
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
+
+## Addendum
+
+This blog thread continues on in the second part!
+
+=> /blog/the_daily/nvme_troubles_part_2 NVMe Troubles Part 2. \ No newline at end of file