On 03/12/2013 06:31 PM, Dave Chinner wrote: > 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... Sure, verified against a new built 3.8.0 kernel, so this should be a regression issue. $ uname -a Linux koala 3.8.0 #81 SMP Tue Mar 12 18:03:44 CST 2013 x86_64 x86_64 x86_64 GNU/Linux commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Mon Feb 18 15:58:34 2013 -0800 Thanks, -Jeff _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
