On Mon, 9 Nov 2015, Sami Tolvanen wrote: > > Also, the 2 other big questions from Mikulas need answering: > > 1) why aren't you actually adjustng error codes, returning success, if > > dm-verity was able to trap/correct the corruption? > > 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. What flash controller and chips do you use? What is the probability of I/O error and what is the probability of silent data corruption? Is the silent data corruption permanent or transient? What is causing the silent data corruption (decay in flash chips?, errors on the bus?) Why can't you ask the hardware engineers to use a controler with proper error correction? Without these data - it looks like you first wrote the patch and then tried to make some excuses why it should be accepted. I'm also a little bit concerned that the patch will increase prevalence of crapware on the market - when accepted, this kind of reasoning will follow: "now we have error correction in the kernel, so we cut down flash overprovisioning, save a dollar or two per device, and produce a crap that randomly corrupts user's data on the read-write partition (because that partition not protected by the error correction)". Mikulas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
