* In Direct I/O, no matter how big the read/write, the bio's are all 4KB
@ 2017-05-09 20:03 Chris Worley
2017-05-09 20:14 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Chris Worley @ 2017-05-09 20:03 UTC (permalink / raw)
To: linuxraid
I realize DIO needs to be 4KB aligned, but why do large I/Os get
chopped down into 4KB bio's?
Doing a blocktrace of the md device, even though the app is writing at
512KB, the MD driver is receiving 4KB bio's.
Why?
Thanks,
Chris
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: In Direct I/O, no matter how big the read/write, the bio's are all 4KB
2017-05-09 20:03 In Direct I/O, no matter how big the read/write, the bio's are all 4KB Chris Worley
@ 2017-05-09 20:14 ` Christoph Hellwig
2017-05-09 21:26 ` Chris Worley
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2017-05-09 20:14 UTC (permalink / raw)
To: Chris Worley; +Cc: linuxraid
On Tue, May 09, 2017 at 10:03:24AM -1000, Chris Worley wrote:
> I realize DIO needs to be 4KB aligned,
Actually many file systems do support sector size aligned direct I/O,
which could be 512 byte aligned. But as that's not your point :)
> but why do large I/Os get
> chopped down into 4KB bio's?
They shouldn't. What kernel version is this on?
> Doing a blocktrace of the md device, even though the app is writing at
> 512KB, the MD driver is receiving 4KB bio's.
The direct I/O code is using bio_add_page to build the bios it submits.
It might be interesting to see which of the checks in it triggers
an early return after the first page.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: In Direct I/O, no matter how big the read/write, the bio's are all 4KB
2017-05-09 20:14 ` Christoph Hellwig
@ 2017-05-09 21:26 ` Chris Worley
2017-05-10 2:47 ` Ming Lei
0 siblings, 1 reply; 4+ messages in thread
From: Chris Worley @ 2017-05-09 21:26 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxraid
On Tue, May 9, 2017 at 10:14 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, May 09, 2017 at 10:03:24AM -1000, Chris Worley wrote:
>> I realize DIO needs to be 4KB aligned,
>
> Actually many file systems do support sector size aligned direct I/O,
> which could be 512 byte aligned. But as that's not your point :)
>
>> but why do large I/Os get
>> chopped down into 4KB bio's?
>
> They shouldn't. What kernel version is this on?
$ uname -r
3.10.0-514.6.2.el7.x86_64
>
>> Doing a blocktrace of the md device, even though the app is writing at
>> 512KB, the MD driver is receiving 4KB bio's.
>
> The direct I/O code is using bio_add_page to build the bios it submits.
> It might be interesting to see which of the checks in it triggers
> an early return after the first page.
I vaguely recall the noop scheduler's only task is to merge adjacent
blocks. In my case, there's "none" (no schedular at all) for all
block devices chained together. Is that the issue?
Thanks,
Chris
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: In Direct I/O, no matter how big the read/write, the bio's are all 4KB
2017-05-09 21:26 ` Chris Worley
@ 2017-05-10 2:47 ` Ming Lei
0 siblings, 0 replies; 4+ messages in thread
From: Ming Lei @ 2017-05-10 2:47 UTC (permalink / raw)
To: Chris Worley; +Cc: Christoph Hellwig, linuxraid
On Wed, May 10, 2017 at 5:26 AM, Chris Worley <worleys@gmail.com> wrote:
> On Tue, May 9, 2017 at 10:14 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> On Tue, May 09, 2017 at 10:03:24AM -1000, Chris Worley wrote:
>>> I realize DIO needs to be 4KB aligned,
>>
>> Actually many file systems do support sector size aligned direct I/O,
>> which could be 512 byte aligned. But as that's not your point :)
>>
>>> but why do large I/Os get
>>> chopped down into 4KB bio's?
>>
>> They shouldn't. What kernel version is this on?
>
> $ uname -r
> 3.10.0-514.6.2.el7.x86_64
>
>>
>>> Doing a blocktrace of the md device, even though the app is writing at
>>> 512KB, the MD driver is receiving 4KB bio's.
>>
>> The direct I/O code is using bio_add_page to build the bios it submits.
>> It might be interesting to see which of the checks in it triggers
>> an early return after the first page.
>
> I vaguely recall the noop scheduler's only task is to merge adjacent
> blocks. In my case, there's "none" (no schedular at all) for all
> block devices chained together. Is that the issue?
It shouldn't be related with scheduler since page is added to bio's bvec
table first. As Christoph mentioned, maybe some queue's limits are violated,
and pages from the 2nd one can't be added into any more. Since it might
depend on specific md setting, could you share your md setting or
detailed reproduction steps?
thanks,
Ming Lei
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-10 2:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-09 20:03 In Direct I/O, no matter how big the read/write, the bio's are all 4KB Chris Worley
2017-05-09 20:14 ` Christoph Hellwig
2017-05-09 21:26 ` Chris Worley
2017-05-10 2:47 ` Ming Lei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).