Re: A lot warnings in dmesg while running thunderbird

[Gabriel C <nix.or.die@gmail.com>]

On 20.07.2016 15:50, Chris Mason wrote:
> 
> 
> On 07/19/2016 08:11 PM, Gabriel C wrote:
>>
>>
>> On 19.07.2016 13:05, Chris Mason wrote:
>>> On Mon, Jul 11, 2016 at 11:28:01AM +0530, Chandan Rajendra wrote:
>>>> Hi Chris,
>>>>
>>>> I am able to reproduce the issue with the 'short-write' program. But before
>>>> the call trace associated with btrfs_destroy_inode(), I see the following call
>>>> trace ...
>>>>
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 2 PID: 2311 at /home/chandan/repos/linux/fs/btrfs/extent-tree.c:4303 btrfs_free_reserved_data_space_noquota+0xe8/0x100
>>>
>>> [ ... ]
>>>
>>> Ok, the problem is in how we're dealing with the offset into the sector when
>>> we fail. The dirty_sectors variable already has this accounted in it, so
>>> this patch fixes it for me.  I ran overnight, but I'll let it go for a few
>>> days just to make sure:
>>>
>>> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
>>> index fac9b839..5842423 100644
>>> --- a/fs/btrfs/file.c
>>> +++ b/fs/btrfs/file.c
>>> @@ -1629,13 +1629,11 @@ again:
>>>  		 * managed to copy.
>>>  		 */
>>>  		if (num_sectors > dirty_sectors) {
>>> -			/*
>>> -			 * we round down because we don't want to count
>>> -			 * any partial blocks actually sent through the
>>> -			 * IO machines
>>> -			 */
>>> -			release_bytes = round_down(release_bytes - copied,
>>> -				      root->sectorsize);
>>> +
>>> +			/* release everything except the sectors we dirtied */
>>> +			release_bytes -= dirty_sectors <<
>>> +				root->fs_info->sb->s_blocksize_bits;
>>> +
>>>  			if (copied > 0) {
>>>  				spin_lock(&BTRFS_I(inode)->lock);
>>>  				BTRFS_I(inode)->outstanding_extents++;
>>>
>>
>> Since I guess you are testing this on latest git code I started to test on latest stable.
> 
> Any v4.7-rc or v4.6 stable where the patch applies ;)
> 
>>
>> Until now all seems file .. your test program is still running without to trigger the bug.
>>
>> Also thunderbird is running without to trigger the bug.
>>
>> I let it run overnight and report back.
> 
> Great, thanks!

After 24h of running the program and thundirbird all is still fine here.

I let it run one more day.. But looks very good.


Regards,

Gabriel