Re: the 1Tb block issue

2010-05-19 Thread Christoph Hellwig
On Tue, May 18, 2010 at 08:38:22PM +0300, Avi Kivity wrote: Yes. Why would Linux post overlapping requests? makes 0x sense. There may be a guest bug in here too. Christoph? Overlapping writes are entirely fine from the guest POV, although they should be rather unusual. We

Re: the 1Tb block issue

2010-05-19 Thread Avi Kivity
On 05/19/2010 11:57 AM, Christoph Hellwig wrote: On Tue, May 18, 2010 at 08:38:22PM +0300, Avi Kivity wrote: Yes. Why would Linux post overlapping requests? makes 0x sense. There may be a guest bug in here too. Christoph? Overlapping writes are entirely fine from the guest

the 1Tb block issue

2010-05-18 Thread Michael Tokarev
I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it fails right on the mkfs stage: mkfs.ext4 /dev/vdb Writing inode tables: end_request: I/O error, dev vdb, sector

Re: the 1Tb block issue

2010-05-18 Thread Daniel P. Berrange
On Tue, May 18, 2010 at 07:52:45PM +0400, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it fails right on the mkfs stage:

Re: the 1Tb block issue

2010-05-18 Thread Michael Tokarev
18.05.2010 19:52, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it fails right on the mkfs stage: mkfs.ext4 /dev/vdb Writing inode tables:

Re: the 1Tb block issue

2010-05-18 Thread Gleb Natapov
On Tue, May 18, 2010 at 08:51:55PM +0400, Michael Tokarev wrote: 18.05.2010 19:52, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. kvm-img create test.raw 1500G kvm ... \ -drive file=test.raw,if=virtio it

Re: the 1Tb block issue

2010-05-18 Thread Avi Kivity
On 05/18/2010 06:52 PM, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. Can you try the patch I just posted? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

Re: the 1Tb block issue

2010-05-18 Thread Avi Kivity
On 05/18/2010 08:34 PM, Michael Tokarev wrote: 18.05.2010 21:29, Avi Kivity wrote: On 05/18/2010 06:52 PM, Michael Tokarev wrote: I just re-verified it on current stable qemu-kvm-0.12.4. The issue is still here, trivial to trigger. Can you try the patch I just posted? Applied this one:

Re: the 1Tb block issue

2010-05-18 Thread Michael Tokarev
18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the usual sector 3145727872. Hmm. Ide has no queue, hence no mergeing, that's

Re: the 1Tb block issue

2010-05-18 Thread Avi Kivity
On 05/18/2010 09:03 PM, Michael Tokarev wrote: 18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not stopping at the usual sector 3145727872.

Re: the 1Tb block issue

2010-05-18 Thread Michael Tokarev
18.05.2010 22:09, Avi Kivity wrote: On 05/18/2010 09:03 PM, Michael Tokarev wrote: 18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At least it went further than before, not

Re: the 1Tb block issue

2010-05-18 Thread Michael Tokarev
18.05.2010 22:38, Michael Tokarev пишет: 18.05.2010 22:09, Avi Kivity wrote: On 05/18/2010 09:03 PM, Michael Tokarev wrote: 18.05.2010 21:38, Avi Kivity wrote: [Qemu-devel] [PATCH +stable] block: don't attempt to merge overlapping requests quick tests shows it works correctly so far. At