QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* Problems with c8bb23cbdbe3 on ppc64le
@ 2019-10-10 15:17 Max Reitz
  2019-10-10 16:15 ` Anton Nefedov
  0 siblings, 1 reply; 3+ messages in thread
From: Max Reitz @ 2019-10-10 15:17 UTC (permalink / raw)
  To: Qemu-block
  Cc: Alberto Garcia, Anton Nefedov, Vladimir Sementsov-Ogievskiy, qemu-devel

[-- Attachment #1.1: Type: text/plain, Size: 591 bytes --]

Hi everyone,

(CCs just based on tags in the commit in question)

I have two bug reports which claim problems of qcow2 on XFS on ppc64le
machines since qemu 4.1.0.  One of those is about bad performance
(sorry, is isn’t public :-/), the other about data corruption
(https://bugzilla.redhat.com/show_bug.cgi?id=1751934).

It looks like in both cases reverting c8bb23cbdbe3 solves the problem
(which optimized COW of unallocated areas).

I think I’ve looked at every angle but can‘t find what could be wrong
with it.  Do any of you have any idea? :-/


Thanks,

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problems with c8bb23cbdbe3 on ppc64le
  2019-10-10 15:17 Problems with c8bb23cbdbe3 on ppc64le Max Reitz
@ 2019-10-10 16:15 ` Anton Nefedov
  2019-10-11  7:49   ` Max Reitz
  0 siblings, 1 reply; 3+ messages in thread
From: Anton Nefedov @ 2019-10-10 16:15 UTC (permalink / raw)
  To: Max Reitz, Qemu-block
  Cc: Vladimir Sementsov-Ogievskiy, Alberto Garcia, qemu-devel

On 10/10/2019 6:17 PM, Max Reitz wrote:
> Hi everyone,
> 
> (CCs just based on tags in the commit in question)
> 
> I have two bug reports which claim problems of qcow2 on XFS on ppc64le
> machines since qemu 4.1.0.  One of those is about bad performance
> (sorry, is isn’t public :-/), the other about data corruption
> (https://bugzilla.redhat.com/show_bug.cgi?id=1751934).
> 
> It looks like in both cases reverting c8bb23cbdbe3 solves the problem
> (which optimized COW of unallocated areas).
> 
> I think I’ve looked at every angle but can‘t find what could be wrong
> with it.  Do any of you have any idea? :-/
> 

hi,

oh, that patch strikes again..

I don't quite follow, was this bug confirmed to happen on x86? Comment 8
(https://bugzilla.redhat.com/show_bug.cgi?id=1751934#c8) mentioned that
(or was that mixed up with the old xfsctl bug?)

Regardless of the platform, does it reproduce? That's comforting
already; worst case we can trace each and every request then (unless it
will stop to reproduce this way).

Also, perhaps it's worth to try to replace fallocate with write(0)?
Either in qcow2 (in the patch, bdrv_co_pwrite_zeroes -> bdrv_co_pwritev)
or in the file driver. It might hint whether it's misbehaving fallocate
(in qemu or in kernel) or something else.

/Anton

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problems with c8bb23cbdbe3 on ppc64le
  2019-10-10 16:15 ` Anton Nefedov
@ 2019-10-11  7:49   ` Max Reitz
  0 siblings, 0 replies; 3+ messages in thread
From: Max Reitz @ 2019-10-11  7:49 UTC (permalink / raw)
  To: Anton Nefedov, Qemu-block
  Cc: Vladimir Sementsov-Ogievskiy, Alberto Garcia, qemu-devel

[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]

On 10.10.19 18:15, Anton Nefedov wrote:
> On 10/10/2019 6:17 PM, Max Reitz wrote:
>> Hi everyone,
>>
>> (CCs just based on tags in the commit in question)
>>
>> I have two bug reports which claim problems of qcow2 on XFS on ppc64le
>> machines since qemu 4.1.0.  One of those is about bad performance
>> (sorry, is isn’t public :-/), the other about data corruption
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1751934).
>>
>> It looks like in both cases reverting c8bb23cbdbe3 solves the problem
>> (which optimized COW of unallocated areas).
>>
>> I think I’ve looked at every angle but can‘t find what could be wrong
>> with it.  Do any of you have any idea? :-/
>>
> 
> hi,
> 
> oh, that patch strikes again..
> 
> I don't quite follow, was this bug confirmed to happen on x86? Comment 8
> (https://bugzilla.redhat.com/show_bug.cgi?id=1751934#c8) mentioned that
> (or was that mixed up with the old xfsctl bug?)

I think that was mixed up with the xfsctl bug, yes.

> Regardless of the platform, does it reproduce? That's comforting
> already; worst case we can trace each and every request then (unless it
> will stop to reproduce this way).

I haven’t been able to reproduce it yet (wrestling with the test system
and getting ppc64 machines provisioned), but as far as I know it
reproduces reliably on ppc64, but only there.

> Also, perhaps it's worth to try to replace fallocate with write(0)?
> Either in qcow2 (in the patch, bdrv_co_pwrite_zeroes -> bdrv_co_pwritev)
> or in the file driver. It might hint whether it's misbehaving fallocate
> (in qemu or in kernel) or something else.

Good idea, that should at least tell us something about the corruption.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-10 15:17 Problems with c8bb23cbdbe3 on ppc64le Max Reitz
2019-10-10 16:15 ` Anton Nefedov
2019-10-11  7:49   ` Max Reitz

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org qemu-devel@archiver.kernel.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox