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

Chris Worley worleys at gmail.com
Mon Sep 22 18:21:32 CEST 2008

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?
> 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?


> Where is this getting fragmented, and any idea how to fix it?
> Thanks,
> Chris
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

More information about the stgt mailing list