@lispi314 good question.

• Maybe because #dmraid as Software-#RAID was tasked with checking itself and the underlying filesystems like #ext3 were taked to check integrity on their level as well?

After all physical device <=> physical volume partution <=> logical volume groups (w/ RAID) <=> filesystems were used in classic #Linux-RAID transparently to each other.

• This also allows for weird shit like =RAID10 with an odd number of drives](https://en.wikipedia.org/wiki/RAID#Non-standard_levels) (just having data duplicated on different drives and striped in one go.

But yeah, you are correct in that an integrity checkibg module was overdue...

@saiki Sollte #btrfs mal nicht der neue Star am Linuxhimmel werden? Besser als #ext3 / #ext4 ? Das schaut mir nicht so aus.

Keine Ahnung, hab das irgendwie aus den Augen verloren, als ich dank Arbeit vorrübergehend immer weniger direkt mit Linux zu tun hatte.

@jonathankoren @neurovagrant Yeah, and AFAICT they mostly support #btrfs, #ext2 / #ext3 / #ext4, #FAT32 and maybe #ExFAT in some cases where the vendor paid $$ per device to #Microsoft.

Mainline #Linux ≠ #Android #toybox / #linux!
As I've gutted most out of the kernel for #OS1337 myself...

@koakuma That being said, it sounds like you're not on some #CoW #filesystem (since the filesystem is under suspicion, rather than only ill-designed #git).

If you're on #ext3 / #ext4, add data=journal, metadata_csum and journal_checksum (the last two are ext4-only) to your mount options, it's quite important to have some bare minimum of usability (still won't help with partial writes, you need transactionality for that).