xfs
[Top] [All Lists]

Re: [PATCH 11/8] xfs_logprint: fix continuation transactions

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 11/8] xfs_logprint: fix continuation transactions
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 09 May 2013 09:59:51 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130501063136.GL10481@dastard>
References: <20130430121300.GB10481@dastard> <20130501063136.GL10481@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 05/01/13 01:31, Dave Chinner wrote:
From: Dave Chinner<dchinner@xxxxxxxxxx>

As demonstrated by xfs/295, continuation transactions cause of
problems for xfs_logprint. The failure demonstrated by the test is
that the buffer log format structures are variable sized on disk -
the dirty bitmap is sized according to the buffer length, not fixed
to the length of the maximum supported buffer size.

xfs_logprint assumes that the buf log format reocrds are of fixed
size, and so when a short buffer is found it fails to handle it
properly and treats it like a continuation record.  This causses the
opheader pointer to be incremented incorrectly and then logprint
wanders off into a dark corner and gets eaten by a grue.

While fixing this, make the xlog_print_record code that does the
transaction opheader walking a little easier to read and stop it
from outputting binary data direct to the console by converting the
no-data-print case to use a hex dumping loop.

Signed-off-by: Dave Chinner<dchinner@xxxxxxxxxx>
---
  logprint/log_misc.c |   22 +++++++++++++++++-----
  1 file changed, 17 insertions(+), 5 deletions(-)


Looks good.

Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>

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