[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