Re: [PATCH] metadump: don't verify metadata being dumped

[Dave Chinner <david@fromorbit.com>]

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@redhat.com>
> > 
> > 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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs