Re: Differences in mkfs.xfs and xfs_info output.

[Eric Sandeen <sandeen@sandeen.net>]

Jan Derfinak wrote:
> Hello.
> 
> I found following problem with xfs_info (xfs_grows -p xfs_info) command:
> 
> # mkfs.xfs -f /dev/loop0     
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> # mount /dev/loop0 /mnt/usb
> # xfs_info /mnt/usb
> meta-data=/dev/loop0             isize=256    agcount=4, agsize=32000 blks
>          =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096  
> log      =internal               bsize=4096   blocks=1200, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> Can somebody explain the difference in attr and lazy-count parameters?
> Which output is the right one?

...

> features2 = 0


Looks like neither XFS_SB_VERSION2_ATTR2BIT nor
XFS_SB_VERSION2_LAZYSBCOUNTBIT is in fact set.

You're on x86_64 aren't you...

This reminds me of an email I sent in 2006....

> If you do a fresh mkfs.xfs on x86_64, with -i attr=2, and dump out the
> superblock (or look at it with xfs_db) you will find that although the
> versionnum says that there is a morebits bit, the features2 flag is 0.
> 
> if you dd/hexdump the superblock, you will find the attr2 flag, but at
> the wrong offset.
> 
> This is because the xfs_sb_t struct is padded out to 64 bits on 64-bit
> arches, and the xfs_xlatesb() routine and xfs_sb_info[] array take this
> padding to mean that the last item is 4 bytes bigger than it is, and
> treats sb_features2 as 8 bytes not four.  This then gets endian-flipped out...

which is exactly what is (still) going on.

if you hexdump out the filesystem that was made you'll see:

....
          sbqf  sv vn inode_algn   sbunit      sbwidth
000000b0  00 00 00 00 00 00 00 02  00 00 00 00 00 00 00 00
|................|
          bl sl lgss     logsunit  features2   (nothing)
000000c0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 08
|................|

that "08" out in no mans land is what would *like* to be features2 - and
if it were, it'd give you attr2.  Urk.

-Eric