Re: AW: bad performance maybe blocksize of LUN related

[FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>]

On Fri, 12 Aug 2011 11:23:45 +0200
"Marcus Schwarz" <m.schwarz@xxxxxx> wrote:

> Hi there,
> 
> > -----Urspr$(D+d(Bngliche Nachricht-----
> > Von: FUJITA Tomonori [mailto:fujita.tomonori@xxxxxxxxxxxxx]
> > Gesendet: Donnerstag, 11. August 2011 16:29
> > An: Marcus Schwarz
> > Cc: stgt@xxxxxxxxxxxxxxx
> > Betreff: Re: bad performance maybe blocksize of LUN related
> > 
> > 
> > You create a file on the file system and use it as an iSCSI logical
> > unit. In such case, tgt can't use the native block size
> > unconditionally.
> > 
> > tgt is supposed to specify the block size per lun but seems the
> > feature is not working correctly. I'll fix it shortly but meanwhile
> > you can the following patch to use the 4096 byte block size
> > unconditionally to see if you can get the performance boost.
> > 
> > 
> > diff --git a/usr/sbc.c b/usr/sbc.c
> > index cb07be6..0cf40be 100644
> > --- a/usr/sbc.c
> > +++ b/usr/sbc.c
> > @@ -41,7 +41,7 @@
> >  #include "spc.h"
> >  #include "tgtadm_error.h"
> > 
> > -#define DEFAULT_BLK_SHIFT 9
> > +#define DEFAULT_BLK_SHIFT 12
> > 
> >  static unsigned int blk_shift = DEFAULT_BLK_SHIFT;
> 
> 
> I applied your patch and recompiled the binarys . Now I get 30-40 MB/s in total.
> 
> What seems a bit strange to me is that when I start the copy from my local disk to the iscsi device I'm getting around 80 MB/s up until the first GB is transfered. After that is continously dropping the transfer rate until it reaches 30 MB/s .

You wrote the data to the page cache (memory) then when the page cache
became full, the data went to the physical disk.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html