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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
