Reposted by Falxie_
i think one big factor (among many) as to why AI has had such a foothold in coding spaces is because the majority of people dont consider programming to be art
Falxie_
@falxie.gay
101 followers 262 following 390 posts
26 | she/her | former swe | bay area, ca | 🏳️🌈🏳️⚧️
![A screenshot of a GitHub issue comment from falxie posted 16 minutes ago:
@Finkregh
I had a very similar issue:
[ 330.239002] Kernel panic - not syncing: zfs: rt={spa=netfire vdev_guid=14793300879273773871 ms_id=3718 ms_allocatable}: removing segment (offset=3a1af51cd000 size=9f9000) not completely overlapped by existing one (offset=3a1af51cd000 size=9f4000)
I was able to fix it with the following change and zfs_recover:
diff --git a/module/zfs/range_tree.c b/module/zfs/range_tree.c
index d73195f1a..3835023f5 100644
--- a/module/zfs/range_tree.c
+++ b/module/zfs/range_tree.c
@@ -531,7 +531,7 @@ zfs_range_tree_remove_impl(zfs_range_tree_t *rt, uint64_t start, uint64_t size,
}
if (!(rstart <= start && rend >= end)) {
- panic("zfs: rt=%s: removing segment "
+ zfs_panic_recover("zfs: rt=%s: removing segment "
"(offset=%llx size=%llx) not completely overlapped by "
"existing one (offset=%llx size=%llx)",
ZFS_RT_NAME(rt),
I'm not entirely sure if it was intended for this to NOT call zfs_panic_recover, but this has allowed my pool to be imported in read write mode and I'm running a scrub against it. I ran memtest86+ against my machine and discovered some errors so I suspect this could be cause by memory corruption.
The comment has a heart reaction.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:v4xd5wkbjan2mynbgf4sekit/bafkreiblmk6t2gxl23uytigrwxt5ryijefrccbhn7ha3hjkl3ac2kvqmay)
