linux-kernel - Re: commit 762380a "block: add notion of a chunk size for request merging" stops io on btrfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jun 2014 10:21:13 +0300
From:	Konstantinos Skarlatos <k.skarlatos@...il.com>
To:	Jens Axboe <axboe@...com>, linux-kernel@...r.kernel.org
CC:	linux-btrfs@...r.kernel.org
Subject: Re: commit 762380a "block: add notion of a chunk size for
 request merging" stops io on btrfs

On 18/6/2014 5:11 πμ, Jens Axboe wrote:
> On 2014-06-17 14:35, Konstantinos Skarlatos wrote:
>> Hi all,
>> with 3.16-rc1  rsync stops writing to my btrfs filesystem and stays at a
>> D+ state.
>> git bisect showed that the problematic commit is:
>>
>> 762380ad9322951cea4ce9d24864265f9c66a916 is the first bad commit
>> commit 762380ad9322951cea4ce9d24864265f9c66a916
>> Author: Jens Axboe <axboe@...com>
>> Date:   Thu Jun 5 13:38:39 2014 -0600
>>
>>      block: add notion of a chunk size for request merging
>>
>>      Some drivers have different limits on what size a request should
>>      optimally be, depending on the offset of the request. Similar to
>>      dividing a device into chunks. Add a setting that allows the driver
>>      to inform the block layer of such a chunk size. The block layer 
>> will
>>      then prevent merging across the chunks.
>>
>>      This is needed to optimally support NVMe with a non-zero stripe 
>> size.
>>
>>      Signed-off-by: Jens Axboe <axboe@...com>
>
> That's odd, should not have any effect since nobody enables stripe 
> sizes in the kernel. I'll double check, perhaps it's not always being 
> cleared.
>
> Ah wait, does the attached help?

Yes, it works! I recompiled at commit 
762380ad9322951cea4ce9d24864265f9c66a916 with your patch and it looks 
ok. Rebooted back to the unpatched kernel and the bug showed up again 
immediately.

The funny thing is that the problem only showed on my (multi-disk) btrfs 
filesystem. / which is on ext4 seems to work fine.

>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/