[stgt] iostat shows all tgt I/O in 512 byte operations... how to coalesce?

[FUJITA Tomonori]

On Mon, 22 Sep 2008 10:21:32 -0600
"Chris Worley" <worleys at gmail.com> wrote:

> On Fri, Sep 19, 2008 at 7:40 PM, Chris Worley <worleys at gmail.com> wrote:
> >
> > I'm running CentOS 5.2 targets w/ a 2.6.24 kernel.  The initiator is
> > Win2003.  On the initiator side, the fs is formated NTFS w/ a 4K block
> > size (and the NTFS block size seems to have nothing to do w/ this
> > issue).
> >
> > Watching iostat on the target side, everything is being written to the
> > underlying disk in 512 byte operations.
> >
> > Best I can tell, it's the Linux side that's fragmenting the I/O.
> >
> > I could get a lot better performance if these were coalesced into
> > larger, variable, block sizes (i.e. what's being written from the
> > initiator side is much larger blocks).
> >
> > Is there something tgtd queries on the disk to get this information?

tgtd doesn't do anything special. It opens a file on your file system
(or a device file such as /dev/sda) and performs read/write system
calls.


> > I don't see an fstat64 use of st_blksize in the source.
> >
> > I can put a dummy md "linear" device atop the disk and set the MD
> > device's chunk size to 4K... then everything to the MD device (as well
> > as to the underlying disk) is passed in 4K blocks... which performs
> > much better (except even larger blocks would get better performance if
> > the user is writing larger blocks... and smaller blocks do a
> > read-modify-write that causes 3x the IO activity to perform).
> 
> I changed the MD to chunk at 8K blocks (and the NTFS on the  w2003
> side to use 8k blocks), and the tgtd was still chunking at 4K blocks.
> 
> Does anybody have an idea where the fragmenting is occurring and/or
> how to stop it?

Not sure, but I think that the problem looks more generic one, not
specific to tgtd, right?
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html