> Nick, thanks for the patch. I'm incorporating the fixes upstream, > but one question that was raised is that (in essence) this allows > IO errors to be hit, yet and the return code from llverfs is 0. > The llverdev/llverfs tools are used not only for finding software > data corruption bugs, but also to verify the underlying media. > > It was definitely a bug in the original code that there was no > error reported during the write phase if there was a short write, > but this was at least caught during the read phase because the > data would be incorrect. > > What I've done is to count errors hit during read and write, and > then exit with a non-zero value if there were any IO errors hit > (as happened in your case), even if the rest of the data was > verified correctly. This allows scanning the whole disk in a > single pass (if there are not too many underlying errors) but > still ensuring there is no false sense of security because the > program exited with 0. > > The current patch can be gotten at: > > https://bugzilla.lustre.org/attachment.cgi?id=25407&action=edit > Thanks! It looks good at first glance: I'll be trying it out before long and will let you know if I come up against any problems. Nick -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
