- 0 Posts
- 594 Comments
Yeah, one would think ESR of all people would get his shit together here. OTOH it’s just a static web page, not handling sensitive user info.
Who sews humans together by their digestive tracts, then stops and goes for a swim?
17·1 day agoNormalize USB-c with screws and we have a deal.
I’M SORRY, I DIDN’T QUITE GRASP WHAT YOU WERE SAYING. COULD YOU REPEAT THAT MORE CLEARLY?
22·6 days agoThe next turn: America has denounced Germany!
I know, but I’m poor and can’t afford RAID1 of the same capacity. Thanks for the advice anyhow.
blake2b checksum, zstd compression, raid1c4 metadata and raid6 data. Kernel 6.12, btrfs-progs 6.17, ECC RAM.
The files in the affected inode haven’t been touched for a few years. Dmesg was something about zstd decompression failed and prevented btrfs send of an incremental snapshot as well as accessing one single file.
Due to the size of the array, I don’t always get around to do a full scrub after a (albeit rare) system crash, so I wrote it off as probably that and didn’t analyze much further at the time.
I’m running a 60TB btrfs RAID with all the bells and whistles myself and just recently had an instance of some file being fucked up (probably just the wrong metadata bit being affected or something), which I noticed because
btrfs sendwould repeatedly crash at that inum. All the redundancy may be there, but sometimes it’s not able to recover automagically.Not hating on btrfs at all - it helped me recover from a few fubar situations that could easily have been total data loss - but magical thinking (about all the fancy features) is dangerous.
We need to protect the innocent oil on board at all cost