On 11/09/2015 08:19 PM, Sami Tolvanen wrote: ... > We don't see actual I/O errors very often. Most corruption we've seen > is caused by flaky hardware that doesn't return errors. However, I can > certainly change to code to attempt recovery in this case too. So if I understand it correctly, there is a simplified flash controller that can send data with bit flips without detection? (IOW in "real" SSD this kind of error should be detected internally by some bad block management?) This is why I asked about some statistics of real visible types of errors. For this use case it makes sense to have error correction here but then we should clearly said that it makes no sense to switch it on for "real" hw that does internal integrity check or error correction (but not authenticated integrity check as dm-verity). ... >> If this error correction feature is going to go upstream we really >> should see any associated userspace enablement also included in >> veritysetup. > > I can look into this. Yes, please, patches do not to be production ready (I can integrate it to veritysetup upstream myself) but it would be very nice that released veritysetup can configure all dm-verity features in the same time the mainline kernel is marked stable. (The same applies for dm-crypt & cryptsetup.) Thanks, Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
