xfs
[Top] [All Lists]

Re: [PATCH] xfs_db: Fix extent record printing on big endian

To: Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH] xfs_db: Fix extent record printing on big endian
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 06 Jul 2012 14:07:10 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <4FE23555.7070606@xxxxxxxxxx>
References: <4FE23555.7070606@xxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
On 6/20/12 3:40 PM, Eric Sandeen wrote:
> Extent records which should have been printed as:
> 
> a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,12,17,0]
> 
> for example, were instead being printed as:
> 
> a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,12884910592,0,0]
> 
> in xfs_db.  It was simply mis-parsing the extent records due to wrong
> #defines for big-endian machines.
> 
> It's been broken since at least xfsprogs-2.6.13, causing xfstests 021
> to fail.

Ping on this one?  I'd like to get 021 passing on big-endian.  Do I need to
do more due diligence on the correctness of it?

addr_f
        (*adf)(iocur_top->data, tfl->offset, next);
                fa_cfsblock(obj, bit, next);
                        bno = (xfs_dfsbno_t)getbitval(obj, bit, 
BMBT_STARTBLOCK_BITLEN,
                                BVUNSIGNED);

fa_cfsblock is getting the wrong "bit" passed to it due to the offset in this 
structure
being wrong, because of the defines in question.  

const field_t   bmapbta_rec_flds[] = {
        { "startoff", FLDT_CFILEOFFA, OI(BMBT_STARTOFF_BITOFF), C1, 0,
          TYP_ATTR },
        { "startblock", FLDT_CFSBLOCK, OI(BMBT_STARTBLOCK_BITOFF), C1, 0,
          TYP_ATTR },
        ...

So we pass it an opaque "obj", and the bit offset into the on-disk inode for 
the extent
data is the same whether we are on big endian or little endian - I think that 
is the
issue here.

getbitval() itself handles endian converions once we get to the right data.  We 
just need
the proper offsets to it...

Thanks,
-Eric
 
> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> ---
> 
> Why this works is, um ...left as an exercise to the reviewer for now ;)
> TBH I get lost in xfs_db, and I'm not sure how endianness is handled,
> but it's pretty clearly not like this!
> 
> diff --git a/db/btblock.c b/db/btblock.c
> index f6e8a68..2c199b2 100644
> --- a/db/btblock.c
> +++ b/db/btblock.c
> @@ -250,23 +250,12 @@ const field_t   bmapbtd_key_flds[] = {
>  };
>  #undef KOFF
>  
> -#ifndef XFS_NATIVE_HOST
> -
>  #define BMBT_EXNTFLAG_BITOFF 0
>  #define BMBT_STARTOFF_BITOFF (BMBT_EXNTFLAG_BITOFF + BMBT_EXNTFLAG_BITLEN)
>  #define BMBT_STARTBLOCK_BITOFF       (BMBT_STARTOFF_BITOFF + 
> BMBT_STARTOFF_BITLEN)
>  #define BMBT_BLOCKCOUNT_BITOFF       \
>       (BMBT_STARTBLOCK_BITOFF + BMBT_STARTBLOCK_BITLEN)
>  
> -#else
> -
> -#define BMBT_EXNTFLAG_BITOFF 63
> -#define BMBT_STARTOFF_BITOFF (BMBT_EXNTFLAG_BITOFF - BMBT_STARTOFF_BITLEN)
> -#define BMBT_STARTBLOCK_BITOFF       85 /* 128 - 43 (other 9 is in first 
> word) */
> -#define BMBT_BLOCKCOUNT_BITOFF       64 /* Start of second 64 bit container 
> */
> -
> -#endif /* XFS_NATIVE_HOST */
> -
>  const field_t        bmapbta_rec_flds[] = {
>       { "startoff", FLDT_CFILEOFFA, OI(BMBT_STARTOFF_BITOFF), C1, 0,
>         TYP_ATTR },
> 
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
> 


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