On 2014-06-18 00:21, Konstantinos Skarlatos wrote:
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 <ax...@fb.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 <ax...@fb.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.
Probably because the multi-disk setup doesn't have hw_sectors set, I'm
guessing. But great, I'll get this upstream asap. Thanks for testing!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
