On Thu, Feb 27, 2014 at 07:43:41PM -0600, Eric Sandeen wrote:
> On 2/27/14, 6:53 PM, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > The discontiguous buffer support series added a verifier check on
> > the metadata buffers before they go written to the metadump image.
> > If this failed, it returned an error, and the restul woul dbe that
> > we stopped processing the metadata and exited, resulting in a
> > truncated dump.
> >
> > xfs_metadump is supposed to dump the metadata in the filesystem
> > for forensic analysis purposes, which means we actually want it to
> > retain any corruptions it finds in the filesystem. Hence running the
> > verifier - even to recalculate CRCs - is the wrong thing to be
> > doing. And stopping the dum pwhen we come across an error is even
> > worse.
> >
> > Therefore remove the code tha truns the verifier and causes all
> > these problems and replace it with a comment explaining why we don't
> > want to run verifiers in the metadump process.
>
> This leaves the net functional change from
> 8ab75c db: enable metadump on CRC filesystems
> as:
>
> @@ -1727,6 +1743,9 @@ copy_inode_chunk(
>
> if (!process_inode(agno, agino + i, dip))
> goto pop_out;
> +
> + /* calculate the new CRC for the inode */
> + xfs_dinode_calc_crc(mp, dip);
> }
> skip_processing:
> if (!write_buf(iocur_top))
>
> which seems a) minimal, but also b) like we shouldn't be recalculating
> CRCs if the point is to copy out existing fs state...?
>
> OTOH if we're obfuscating, we would HAVE to recalculate CRCs,
> but then would lose the info that the CRC was bad before.
>
> So probably should skip CRC recalculating if the original CRC
> was bad, in the obfuscating case?
Yeah, you are right - I wasn't thinking of the obfuscation case
changing the metadata....
> Maybe this patch stands ok on its own but it seems like there's
> more work to do. :)
I'll rework it.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|