Am Mon, 12 Sep 2016 04:36:07 +0000 (UTC) schrieb Duncan <1i5t5.dun...@cox.net>:
> Again, I once thought all this was just the stage at which btrfs was, > until I found out that it doesn't seem to happen if btrfs compression > isn't being used. Something about the way it recovers from checksum > errors on compressed data differs from the way it recovers from > checksum errors on uncompressed data, and there's a bug in the > compressed data processing path. But beyond that, I'm not a dev and > it gets a bit fuzzy, which also explains why I've not gone code > diving and submitted patches to try to fix it, myself. I suspect that may very well come from the decompression routine which crashes - and not from btrfs itself. So essentially, the decompression needs to be fixed instead (which probably slows it down by factors). Only when this is tested and fixed, one should look into why btrfs fails when decompression fails. -- Regards, Kai Replies to list-only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
