Hello Eric, Friday, June 9, 2006, 5:16:29 PM, you wrote:
ES> On Fri, Jun 09, 2006 at 06:16:53AM -0700, Robert Milkowski wrote: >> bash-3.00# zpool status -v nfs-s5-p1 >> pool: nfs-s5-p1 >> state: ONLINE >> status: One or more devices has experienced an unrecoverable error. An >> attempt was made to correct the error. Applications are unaffected. >> action: Determine if the device needs to be replaced, and clear the errors >> using 'zpool clear' or replace the device with 'zpool replace'. >> see: http://www.sun.com/msg/ZFS-8000-9P >> scrub: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> nfs-s5-p1 ONLINE 0 0 2 >> c4t600C0FF00000000009258F7A4F1BC601d0 ONLINE 0 0 2 >> >> errors: No known data errors >> bash-3.00# >> >> As you can see there's no protection with ZFS. >> Does it mean that those two checksum errors were related to metadata >> and thanks to ditto blocks it was corrected? (I assume application did >> receive proper data and fs is ok). ES> Hmm, I'm not sure. There are no persistent data errors (as shown by the ES> 'errors:' line), so you should be. If you want to send your ES> /var/fm/fmd/errlog, or 'fmdump -eV' output, we can take a look at the ES> details of the error. If this is the case, then it's a bug that the ES> checksum error is reported for the pool for a recovered ditto block. ES> You may want to try 'zpool clear nfs-s5-p1; zpool scrub nfs-s5-p1' and ES> see if it turns up anything. Well, I just did 'fmdump -eV' and last entry is from May 31th and is related to pools which are already destroyed. I can see another 1 checksum error in that pool (I did zpool clear last time) and it's NOT reported by fmdump. This one occuerd afet May 31th. I hope these are ditto blocks and nothing else (read: bad). System is b39 SPARC. -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
