[Top] [All Lists]

Re: [PATCH] xfsdump: enable dump header checksums

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: [PATCH] xfsdump: enable dump header checksums
From: Alex Elder <aelder@xxxxxxx>
Date: Tue, 20 Sep 2011 11:55:40 -0500
Cc: <xfs@xxxxxxxxxxx>
In-reply-to: <4E77DBB9.7060400@xxxxxxx>
References: <1314654106-28548-1-git-send-email-wkendall@xxxxxxx> <1316463141.2941.75.camel@doink> <4E77DBB9.7060400@xxxxxxx>
Reply-to: <aelder@xxxxxxx>
On Mon, 2011-09-19 at 19:18 -0500, Bill Kendall wrote:
> On 09/19/2011 03:12 PM, Alex Elder wrote:
. . .
> > The theory in doing this unconditionally is that we might as
> > well record it, even if the restore program chooses to ignore
> > it, right?
> Right. (You probably noticed this also changes restore to
> unconditionally verify the checksum, provided the flags
> indicate the checksum was recorded.)

It *might* be nice to have an option to ignore the
checksum on restore.  I don't know though.  I was
thinking it might be useful if whatever dumped the
data did a buggy checksum but, well, we have no
evidence that xfsdump has ever done that.

. . .
> > I know it's fairly obvious on these simple functions, but it
> > might be nice to state in the header that the number of bytes
> > used in the checksum is a multiple of 4, and that endp marks
> > a point *beyond* the last byte used.
> I've changed this to be more conventional and take a length
> argument rather than an end pointer. Also added a comment
> about the length restriction.

I was going to suggest using length, so that sounds good
to me.


<Prev in Thread] Current Thread [Next in Thread>