Date: Wed, 13 Jul 2011 11:01:40 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Artem Belevich" <art@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: Forcing a full file read in ZFS even when checksum error encountered Message-ID: <94D74687DE95420486730136248EEB77@multiplay.co.uk> References: <69E82BC1AF1E4F50B37119C4E614B190@multiplay.co.uk> <CAFqOu6iPzbZSZ3gwC5pu=Swk1z=L-dkZ-aarXDESoHnMJuHWyg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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=407 Perfect, thanks Artem. For the record using the following zdb commands I've managed to get the file data off the pool. 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 e.g. zdb -dddd tank/usr zdb -ddddd tank/usr 1243 zdb -R tank:0:22df120000:18000:r 2>corrupt.jpg Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94D74687DE95420486730136248EEB77>