David Lethe wrote: > Read ... What? All I have is block x on physical device y. Granted zfs > recalculates parity, but zfs won't do this unless I can read the appropriate > storage pool and offset. >
Read the data (file) which is using the block. When you scrub a ZFS file system, if a bad block is detected and it cannot be fixed, then zfs status -v will show which file is affected. Scrubbing works by reading, which automatically does checksum validation and stimulates the repair process, as needed. It seems to me that you are trying to do the same thing, but from the bottom up. You might take a look at how bad blocks are simulated in zdb (-B option). zdb isn't well documented beyond the source, though. -- richard > Or are you saying that if do a raw read on the bad block via, dd for instance > that zfs will monitor the sensecode for the read error and magically fix it? > > Is there a completely different technique I can use that let's me inform the > os that block x, drive y is corrupt ... that zfs will take notice of and > initiate a targeted parity rebuild? or a way to do a limited badblock scan > for physical drive where I can pass the starting and ending blocks? > > > > -----Original Message----- > > From: "Richard Elling" <[EMAIL PROTECTED]> > Subj: Re: [zfs-discuss] Repairing known bad disk blocks before zfs > encounters them > Date: Wed Apr 16, 2008 12:36 pm > Size: 1K > To: "David" <[EMAIL PROTECTED]> > cc: "zfs-discuss@opensolaris.org" <zfs-discuss@opensolaris.org> > > David wrote: > >> I have some code that implements background media scanning so I am able to >> detect bad blocks well before zfs encounters them. I need a script or >> something that will map the known bad block(s) to a logical block so I can >> force zfs to repair the bad block from redundant/parity data. >> >> I can't find anything that isn't part of a draconian scanning/repair >> mechanism. Granted the zfs architecture can map physical block X to >> logical block Y, Z, and other letters of the alphabet .. but I want to go >> backwards. >> >> 2nd part of the question .. assuming I know /dev/dsk/c0t0d0 has an ECC error >> on block n, and I now have the appropriate storage pool info & offset that >> corresponds to that block, then how do I force the file system to repair the >> offending block. >> >> This was easy to address in LINUX assuming the filesystem was built on the >> /dev/md driver, because all I had to do is force a read and twiddle with the >> parameters to force a non-cached I/O and subsequent repair. >> >> > > Just read it. > -- richard > > >> It seems as if zfs's is too smart for it's own good and won't let me fix >> something that I know is bad, before zfs has a chance to discover it for >> itself. :) >> >> >> This message posted from opensolaris.org >> _______________________________________________ >> 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
