Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I only know about FAT but these "key file metadata blocks" are redundant, so you need really special double-plus bad luck to do that.


It was ext4, and I’ve had it happen two different times - in fact, I’ve never had it happen in a ‘good’ recoverable way before that I’ve ever seen.

It triggered a kernel panic in every machine that I mounted it in, and it wasn’t a media issue either. Doing a block level read of the media had zero issues and consistently returned the exact same data the 10 times I did it.

Notably, I had the same thing happen using btrfs due to power issues on a Raspberry Pi (partially corrupted writes resulting in a completely unrecoverable filesystem, despite it being in 2x redundancy mode).

Should it be impossible? Yes. Did it definitely, 100% for sure happen? You bet.

I never actually lost data on ZFS, and I’ve done some terrible things to pools before that took quite awhile to unbork, including running it under heavy write load with a machine with known RAM problems and no ECC.


Good to know. Ext2 is much more robust against corruption. Or at least it was 10 years ago when i had kernel crashes or power failures.


so I can consider myself very lucky and unlucky at the same time. I had data corruption on zfs filesystem that destroyed whole pool to unrecoverable state (zfs was segfaulting while trying to import, all recovery zfs features where crashing zfs module and required reboot) the lucky part is that this happened just after (something like next day) I migrated whole pool to another (bigger) server/pool so that system was already scheduled for full disk wipe


This happened to me too. The root cause was a bad memory stick.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: