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> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
