On Fri, 4 Aug 2017 12:44:44 +0500 Roman Mamedov <r...@romanrm.net> wrote:
> > What is 0x98f94189, is it not a csum of a block of zeroes by any chance? > > It does seem to be something of that sort Actually, I think I know what happened. I used "dd bs=1M conv=sparse" to copy source FS onto a LUKS device, which skipped copying 1M-sized areas of zeroes from the source device by seeking over those areas on the destination device. This only works OK if the destination device is entirely zeroed beforehand. But I also use --allow-discards for the LUKS device; so it may be that after a discard passthrough to the underlying SSD, which will then return zeroes for discarded areas, LUKS will not take care to pass zeroes back "upwards" when reading from those areas, instead it may attempt to decrypt them with its crypto process, making them read back to userspace as random data. So after an initial TRIM the destination crypto device was not actually zeroed, far from it. :) As a result, every large non-sparse file with at least 1MB-long run of zeroes in it (those sqlite ones appear to fit the bill) was not written out entirely onto the destination device by dd, and the intended zero areas were left full of crypto-randomness instead. Sorry for the noise, I hope at least this catch was somewhat entertaining. And Btrfs saves the day once again. :) -- With respect, Roman -- 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
