[ENBD] Doubled requests
Peter T. Breuer
ptb at it.uc3m.es
Wed Jan 14 04:35:38 MST 2004
"Also sprach Arne Wiebalck:"
> On Wed, 14 Jan 2004, Peter T. Breuer wrote:
> > file 12180: <#1007> fileit two consecutive writes to the same place!
> > file 12180: <#1010> fileit 0x131000-0x131400 and 0x131000-131400!
> > file 12180: <#1007> fileit two consecutive writes to the same place!
> > file 12180: <#1010> fileit 0x131400-0x131800 and 0x131400-131800!
>
> Aha! Very good.
>
> > That's 1K blocks too. I'll ivestigae.
> >
>
> > > BUT: it seems that you already "impemented" a switch for the doubled
> > > requests, it's called "merge_requests"! in one of the last tests I forgot
> > > to activate it and now it transferred several 100,000 writes with no
> > > twins. I'll investigate further ....
I am running with m_r off.
> > Hmm. Maybe an artefact of effective block size?
>
> What is the "effective block size"? Something the driver uses to
I mean the average size of requests arriving at the server end.
> merge requests? Is merging requests also related to plugging as you
> desribed in the former mail? Sounds similar.
Yes - when the kernel is "plugging" it is also merging requests.
> May it be that by mergeing the requests inside the enbd driver sometimes
> a bh is doubled? Mergeing requests means reusing a single request
> structure for multiple buffer_heads, right?
Yes. But it is done by the kernel, not by the driver.
> btw, I could write 1,000,000 blocks with merge_requests switched off and I
> did not see a single twin.
file 12732: <#1017> fileit two consecutive writes to the same place!
file 12732: <#1020> fileit 0x3fbc00-0x3fc000 and 0x3fbc00-3fc000!
file 12732: <#1023> fileit we thought we were at 0x7f7000 and think we are at 0x7f7400
file 12732: <#1026> fileit last time we entered for 0x3fb800-3fbc00 (#0) and now for 0x3fb800-0x3fbc00 (#0)
I see it with m_r off and blocksize 1K. Haven't tried anything else.
Urr yes I have. Turning m_r on makes no difference.
The <#1023> line above indicates a possible problem.
The <#1026> line seems to show that these are actually different calls
to fileit(), or at least that this is the first time through the
interior loop each time (#0). Will check. Yes - they are.
fileit last time we entered for 0x3e8000-3e8400 (#7218:0) and now
for 0x3e8000-0x3e8400 (#7219:0)
Consecutive calls to fileit with the same params. OK. That narrows this
down. I'll be back after I move to my office ...
Peter
More information about the ENBD
mailing list