>>>>> "Malahal" == malahal <malahal@xxxxxxxxxx> writes: Malahal> Your problem is very similar to an iSCSI problem sumitted Malahal> here: Malahal> http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=137902 Can't see it without a netapp account... Malahal> Fortunately, you can detect the problem and the I/O can be Malahal> retried if possible. That's not entirely trivial. Obviously the original data that matches the checksum is gone. And I don't want to blindly regenerate the checksum from the new data (how do I know this was an "ok" kind of corruption?). The only one that has that knowledge is the filesystem. And if the filesystem needs to be integrity-aware, I'd much rather have it Do The Right Thing than teach it to inspect and reissue I/Os that come back with -EDANGERWILLROBINSON. With ext2 at least this is not some rare corner case. It happens hundreds of times during an unpack of a kernel tarball. We'd end up burning many, many cycles doing retries. -- Martin K. Petersen Oracle Linux Engineering -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
