I'll be doing this over the upcoming weekend so I'll see how it goes. Thanks for all of the suggestions.
Todd On Jun 22, 2011, at 10:48 AM, Cindy Swearingen <cindy.swearin...@oracle.com> wrote: > Hi Todd, > > Yes, I have seen zpool scrub do some miracles but I think it depends > on the amount of corruption. > > A few suggestions are: > > 1. Identify and resolve the corruption problems on the underlying > hardware. No point in trying to clear the pool errors if this > problem continues. > > The fmdump command and the fmdump -eV command output will > tell you how long these errors have occurred. > > 2. Run zpool scrub and zpool clear to attempt to clear the errors. > > 3. If the errors below don't clear, then manually remove the corrupted > files below, if possible, and restore from backup. Depending on what > fmdump says, you might check your backups for corruption. > > 4. Run zpool scrub and zpool clear again as needed. > > 5. Consider replacing this configuration with a redundant ZFS storage > pool. We can provide the recommended syntax. > > Let us know how this turns out. > > Thanks, > > Cindy > > On 06/20/11 23:36, Todd Urie wrote: >> I have a zpool that shows the following from a zpool status -v <zpool name> >> brsnnfs0104 [/var/spool/cron/scripts]# zpool status -v ABC0101 >> pool:ABC0101 >> state: ONLINE >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://www.sun.com/msg/ZFS-8000-8A >> scrub: none requested >> config: >> NAME STATE READ WRITE CKSUM >> ABC0101 ONLINE 0 0 10 >> /dev/vx/dsk/ABC01dg/ABC0101_01 ONLINE 0 0 2 >> /dev/vx/dsk/ABC01dg/ABC0101_02 ONLINE 0 0 8 >> /dev/vx/dsk/ABC01dg/ABC0101_03 ONLINE 0 0 10 >> errors: Permanent errors have been detected in the following files: >> >> /clients/ABC0101/rep/local/bfm/web/htdocs/tmp/rscache/717b52282ea059452621587173561360 >> >> /clients/ABC0101/rep/local/bfm/web/htdocs/tmp/rscache/6e6a9f37c4d13fdb3dcb8649272a2a49 >> >> /clients/ABC0101/rep/d0/prod1/reports/ReutersCMOLoad/ReutersCMOLoad.ABCntss001.20110620.141330.26496.ROLLBACK_FOR_UPDATE_COUPONS.html >> >> /clients/ABC0101/rep/local/bfm/web/htdocs/tmp/G2_0.related_detail_loader.1308593666.54643.n5cpoli3355.data >> >> /clients/ABC0101/rep/d0/prod1/reports/gp_reports/ALLMNG/20110429/F_OLPO82_A.gp.ABCIM_GA.nlaf.xml.gz >> >> /clients/ABC0101/rep/d0/prod1/reports/gp_reports/ALLMNG/20110429/UNVLXCIAFI.gp.ABCIM_GA.nlaf.xml.gz >> >> /clients/ABC0101/rep/d0/prod1/reports/gp_reports/ALLMNG/20110429/UNIVLEXCIA.gp.BARCRATING_ABC.nlaf.xml.gz >> I think that a scrub at least has the possibility to clear this up. A quick >> search suggests that others have had some good experience with using scrub >> in similar circumstances. I was wondering if anyone could share some of >> their experiences, good and bad, so that I can assess the risk and >> probability of success with this approach. Also, any other ideas would >> certainly be appreciated. >> -----RTU >> ------------------------------------------------------------------------ >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
