So I took a look at Oracle's documentation.
http://docs.oracle.com/cd/E19082-01/817 ... index.html "Each error would indicate only that an error occurred at a given point in time. Each error is not necessarily still present on the system." Note that "A complete scrub of the pool is guaranteed to examine every active block in the pool, so the error log is reset whenever a scrub finishes."
http://docs.oracle.com/cd/E19082-01/817 ... index.html"The zpool status command also shows whether any known errors are associated with the pool. These errors might have been found during disk scrubbing or during normal operation."
Regarding scrubbing status errors: "The third section of the zpool status output describes the current status of any explicit scrubs. This information is distinct from whether any errors are detected on the system, though this information can be used to determine the accuracy of the data corruption error reporting. If the last scrub ended recently, most likely, any known data corruption has been discovered."
Also Oracle discusses the case where the files are not identifiable:
http://docs.oracle.com/cd/E19082-01/817 ... index.html "If the object number to a file path cannot be successfully translated, either due to an error or because the object doesn't have a real file path associated with it, as is the case for a dnode_t, then the dataset name followed by the object's number is displayed."
In your first post, you noted 3 data errors, with only 2 scrub errors. I'm wondering if that third error occurred after the completion of the scrub. How long had it been since the scrub's completion? Did you run any commands in the interim?
Your conjecture, "Only three files, so I assume that the five errors are spread across the three files," sounds possible, but not necessarily true, given Oracle's remark "Each error would indicate only that an error occurred at a given point in time. Each error is not necessarily still present on the system." It could be the case that other, perhaps unrelated, errors occurred which are no longer present.
At the end of your scrub that completed Tue Mar 5 19:13:06 2013 the number of scrub errors (2) matched the number of files with permanent errors (2). I'm wondering if sudo zpool status twoz, without verbosity, would have reported exactly 2 data errors right at the end of the scrub, given that the log is supposed to reset at the end of a scrub. That would confirm scrub errors = non-verbose data errors at end of scrub = number of files with permanent errors at end of scrub, and confirm the idea that some additional third error occurred after your original scrub on Sun Mar 3 21:28:19 2013.
And is it in fact that the case that scrub actually fixed twoz:/macbookpro08-centrim.sparsebundle/bands/3252? That would be good!