Date: Wed, 13 Jul 2011 16:49:46 +0200 From: Thomas Vogt <freebsdlists@bsdunix.ch> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered Message-ID: <39788F1B-DCF5-488C-8033-5628B97D4592@bsdunix.ch> In-Reply-To: <94D74687DE95420486730136248EEB77@multiplay.co.uk> References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> <CAFqOu6iPzbZSZ3gwC5pu=Swk1z=L-dkZ-aarXDESoHnMJuHWyg@mail.gmail.com> <94D74687DE95420486730136248EEB77@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Steven On Jul 13, 2011, at 12:01 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Artem Belevich" <art@freebsd.org> >> Maybe. See here: >> http://blogs.oracle.com/relling/entry/holy_smokes_a_holey_file >> Using that method you still would not get the bad block, but you may >> be able to recover data beyond it. >> If you really want to get access to the data that ZFS considers to be >> corrupted, you need to get close and personal with zdb. >> This blog post may be a good starting point: = http://cuddletech.com/blog/?p=3D407 >=20 > Perfect, thanks Artem. >=20 > For the record using the following zdb commands I've managed to get = the > file data off the pool. >=20 > 1. zdb -dddd <pool>/<dataset> (find the objectid by searching for the > filename) > 2. zdb -ddddd <pool>/<dataset> <objectid> (find the indirect blocks, = the > third block of hex) > 3. zdb -R <pool>:<indirect blocks> 2>/tmp/filedata >=20 > e.g. > zdb -dddd tank/usr > zdb -ddddd tank/usr 1243 > zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg Which ZFS version do you have? zdb core dumps on all my ZFS 28 with = 8-Stable if i use multiple -dd options.=20 Regards, Thomas=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39788F1B-DCF5-488C-8033-5628B97D4592>