Re: [ASSERT failure] transaction reservations changes bad?

[Dave Chinner <david@fromorbit.com>]

On Tue, Mar 12, 2013 at 04:08:20PM +0800, Jeff Liu wrote:
> Hi Dave,
> 
> On 03/12/2013 02:25 PM, Dave Chinner wrote:
> > On Tue, Mar 12, 2013 at 05:20:02PM +1100, Dave Chinner wrote:
> >> Folks,
> >>
> >> I just got this ASSERT failure running xfstests on a 3.1.8 xfsprogs
> >> and a 3.9-rc1 kernel running test 297:
> > 
> > FYI, it's 100% reproducable here with:
> > 
> > # sudo MKFS_OPTIONS="-b size=512" ./check 297
> > 
> > (reproduced on multiple VMs now with the same command line)
....
> >> This implies that the permanent transaction reservation ended up
> >> larger than the log itself:
> >>
> >> $ sudo xfs_info /mnt/scratch/
> >> [sudo] password for dave: 
> >> meta-data=/dev/vdb               isize=256    agcount=16, agsize=1441792 blks
> >>          =                       sectsz=512   attr=2
> >> data     =                       bsize=512    blocks=23068672, imaxpct=25
> >>          =                       sunit=512    swidth=6144 blks
> >> naming   =version 2              bsize=4096   ascii-ci=0
> >> log      =internal               bsize=512    blocks=2560, version=2
> >>          =                       sectsz=512   sunit=512 blks, lazy-count=1
> >> realtime =none                   extsz=4096   blocks=0, rtextents=0
> >>
> >> Can someone please check that the before/after mkdir transaction
> >> reservation sizes are unchanged for such a configuration?
> I just did a quick verification. 
> 
> # mkfs.xfs -V
> mkfs.xfs version 3.1.8
> 
> # uname -a
> Linux koala 3.9.0-rc1 #80 SMP Tue Mar 12 15:06:39 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> # mkfs.xfs -f -b size=512 /dev/sda6
> meta-data=/dev/sda6              isize=256    agcount=4, agsize=5242880 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=512    blocks=20971520, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=512    blocks=20480, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0

That's a different mkfs.xfs config to what test 297 is using.
Different log size, different AG count, no log stripe unit, etc.
297 is using:

scratch_mkfs_xfs -d agcount=16,su=256k,sw=12 -l su=256k,size=2560b <dev>

And when I add the extra MKFS_OPTIONS in it actually is:

# mkfs.xfs -b size=512 -d agcount=16,su=256k,sw=12 -l su=256k,size=2560b <dev>

> The reservation size does not changed, both are 70072 bytes:
> 
> [  230.905092] xfs_calc_mkdir_reservation: res=70072 bytes.

And it's not just the calculation that I'm worried about here - it's
the actual reservation that ends up in the ticket that matters as
that is fed into the code that has triggered the assert. The value
in the ticket takes into account log stripe units and other
roundings, so it's typically much larger than just the reservation
calculation itself...

> However, I can always reproducing this issue with
> '"MKFS_OPTIONS=-b size=512" ./check 297' as well.

Can you check that it also fails on kernels prior to the reservation
changes? That will rule out it being a recent regression...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs