xfs
[Top] [All Lists]

Re: [ASSERT failure] transaction reservations changes bad?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [ASSERT failure] transaction reservations changes bad?
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Tue, 12 Mar 2013 19:05:43 +0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130312103138.GN21651@dastard>
References: <20130312062001.GJ21651@dastard> <20130312062531.GK21651@dastard> <513EE274.6090808@xxxxxxxxxx> <20130312103138.GN21651@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
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

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