Yes, I use IDE since I boot from this LUN.
I just managed to track it down to the IDE changes.
It looks like basically this change triggered it :
commit bef0fd5958120542f126f2dedbfce65d8839a94d
Author: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com>
Date: Thu Mar 29 10:31:30 2012 +0100
ide: convert ide_sector_read() to asynchronous I/O
Stefan, any ideas? Ill continue trying to understand the IDE code
tomorrow and maybe I make some progress.
regards
ronnie sahlberg
On Mon, May 21, 2012 at 8:45 PM, Kevin Wolf <kw...@redhat.com> wrote:
> Am 21.05.2012 08:07, schrieb ronnie sahlberg:
>> List, Kevin,
>>
>> Since this merge :
>> commit 1f8bcac09af61e58c5121aa0a932190700ad554d
>> Merge: cb4c254 1042ec9
>> Author: Anthony Liguori <aligu...@us.ibm.com>
>> Date: Mon Apr 23 14:27:04 2012 -0500
>>
>> Merge remote-tracking branch 'kwolf/for-anthony' into staging
>>
>> * kwolf/for-anthony: (38 commits)
>> qemu-iotests: Fix test 031 for qcow2 v3 support
>> qemu-iotests: Add -o and make v3 the default for qcow2
>> qcow2: Zero write support
>> qemu-iotests: Test backing file COW with zero clusters
>> qemu-iotests: add a simple test for write_zeroes
>> qcow2: Support for feature table header extension
>> qcow2: Support reading zero clusters
>> qcow2: Version 3 images
>> qcow2: Ignore reserved bits in check_refcounts
>> qcow2: Ignore reserved bits in refcount table entries
>> qcow2: Simplify count_cow_clusters
>> qcow2: Refactor qcow2_free_any_clusters
>> qcow2: Ignore reserved bits in L1/L2 entries
>> qcow2: Fail write_compressed when overwriting data
>> qcow2: Ignore reserved bits in count_contiguous_clusters()
>> qcow2: Ignore reserved bits in get_cluster_offset
>> qcow2: Save disk size in snapshot header
>> Specification for qcow2 version 3
>> qcow2: Fix refcount block allocation during qcow2_alloc_cluster_at()
>> iotests: Resolve test failures caused by hostname
>> ...
>>
>> I am seeing some weirdness when using iscsi.
>> I have isolated it to this particular commit, but since it is 3900
>> lines in sinze I have not yet found the exact change that triggers
>> this particular behaviour.
>>
>> It shows up when using an iscsi device to boot from, where when during
>> the bios boot and later grub boot almost all I/O has a pause of 55ms
>> between them.
>>
>> During boot the bios and later grub will read a lot of data, primarily
>> sequentially and one single block at a time.
>> After these changes were applied there is now an approximate 55ms
>> delay between all these I/O, causing the boot process to become very
>> slow.
>>
>>
>> I have not yet found the exact part of this big patch that cause this
>> slowdown, but will continue investigating.
>>
>> I am posting this here in case someone has any idea or if 55ms rings any
>> bells.
>
> The only thing in this merge that looks as if it could be related is
> Paolo's AIO changes between commit adfe92f6 and 9eb0bfca.
>
> Or if you use IDE, Stefan's patches to make PIO operations asynchronous
> could be related.
>
> Kevin
