Message ID | 50F976D8.60303@redhat.com |
---|---|
State | New |
Headers | show |
Am 18.01.2013 17:22, schrieb Paolo Bonzini: > I haven't written a testcase for it, it's tricky but should be doable. > Do you want me to respin, or can it be done as a followup? I think I would prefer a respin, but if you think otherwise, I won't insist. > I would prefer a followup also because it will give a better pointer when > we backport this fix to the RHEL6 code. That's not really a valid argument for upstream. Also, wouldn't we backport the fixed version in the first place so that a pointer isn't even needed? This code doesn't seem to exist yet in RHEL 6. Kevin
> Am 18.01.2013 17:22, schrieb Paolo Bonzini: > > I haven't written a testcase for it, it's tricky but should be > > doable. > > Do you want me to respin, or can it be done as a followup? > > I think I would prefer a respin, but if you think otherwise, I won't > insist. Okay, I'll respin. I'll just note that this series now is in danger of missing 1.4 (after 1.2 and 1.3) because only Laszlo and Eric gave it a decent review in the six months since it was first posted. Had I been employed by any other company, I'd probably just have kept the code in house and forgotten about upstream. > Also, wouldn't we backport the fixed version in the first place so that > a pointer isn't even needed? This code doesn't seem to exist yet in > RHEL 6. Oops, you're right. We fixed the problem in a different way. Paolo
Am 18.01.2013 18:33, schrieb Paolo Bonzini: > >> Am 18.01.2013 17:22, schrieb Paolo Bonzini: >>> I haven't written a testcase for it, it's tricky but should be >>> doable. >>> Do you want me to respin, or can it be done as a followup? >> >> I think I would prefer a respin, but if you think otherwise, I won't >> insist. > > Okay, I'll respin. I'll just note that this series now is in danger of > missing 1.4 (after 1.2 and 1.3) because only Laszlo and Eric gave it a > decent review in the six months since it was first posted. > > Had I been employed by any other company, I'd probably just have kept > the code in house and forgotten about upstream. I hope this doesn't imply that you feel I'm happy or even just indifferent about it. This is just what happens when you get a huge numbers of patches and have only very few reviewers. I hope it has got a bit better since Stefan supports me in maintaining the block layer, but I'm afraid we're still not good enough with it. Any helpful suggestions are appreciated. Kevin
Il 21/01/2013 11:17, Kevin Wolf ha scritto: > Am 18.01.2013 18:33, schrieb Paolo Bonzini: >> >>> Am 18.01.2013 17:22, schrieb Paolo Bonzini: >>>> I haven't written a testcase for it, it's tricky but should be >>>> doable. >>>> Do you want me to respin, or can it be done as a followup? >>> >>> I think I would prefer a respin, but if you think otherwise, I won't >>> insist. >> >> Okay, I'll respin. I'll just note that this series now is in danger of >> missing 1.4 (after 1.2 and 1.3) because only Laszlo and Eric gave it a >> decent review in the six months since it was first posted. >> >> Had I been employed by any other company, I'd probably just have kept >> the code in house and forgotten about upstream. > > I hope this doesn't imply that you feel I'm happy or even just > indifferent about it. This is just what happens when you get a huge > numbers of patches and have only very few reviewers. I hope it has got a > bit better since Stefan supports me in maintaining the block layer, but > I'm afraid we're still not good enough with it. Any helpful suggestions > are appreciated. No, I don't think you're happy. And I'm sorry if it felt like a complaint, it wasn't meant to be---I had plenty of other patches committed by either you or Stefan or Anthony, so I cannot really complain about anything. :) The problem is that we have lots of patches that are not ready posted too early without really following comments. These patches consume a huge amount of review bandwidth. And more often than not are never committed because people disappear when they are almost ready. At the same time, patches that are almost ready from the beginning, tend to fall through the cracks. It is not exclusive to the block layer, see for example Alberto Garcia's serial port patches. Paolo
Il 18/01/2013 17:22, Paolo Bonzini ha scritto: >> > If it does, we mark the whole cluster dirty now, but in the cow_bitmap >> > it's still marked at present on the target. When restarting the job, >> > wouldn't it copy only the start of the cluster next time and corrupt the >> > rest of it? > Yes, very good catch. Actually, it works. Because the whole destination cluster is marked dirty, all of it is ultimately copied correctly. The special handling of COW is required for all others sources of dirty data, where the dirty bitmap can include a subset of a destination cluster, but not in this case. I'll include the testcase, and test the patch I attached to my previous message. Paolo
On Mon, Jan 21, 2013 at 12:15:51PM +0100, Paolo Bonzini wrote: > Il 21/01/2013 11:17, Kevin Wolf ha scritto: > > Am 18.01.2013 18:33, schrieb Paolo Bonzini: > >> > >>> Am 18.01.2013 17:22, schrieb Paolo Bonzini: > >>>> I haven't written a testcase for it, it's tricky but should be > >>>> doable. > >>>> Do you want me to respin, or can it be done as a followup? > >>> > >>> I think I would prefer a respin, but if you think otherwise, I won't > >>> insist. > >> > >> Okay, I'll respin. I'll just note that this series now is in danger of > >> missing 1.4 (after 1.2 and 1.3) because only Laszlo and Eric gave it a > >> decent review in the six months since it was first posted. > >> > >> Had I been employed by any other company, I'd probably just have kept > >> the code in house and forgotten about upstream. > > > > I hope this doesn't imply that you feel I'm happy or even just > > indifferent about it. This is just what happens when you get a huge > > numbers of patches and have only very few reviewers. I hope it has got a > > bit better since Stefan supports me in maintaining the block layer, but > > I'm afraid we're still not good enough with it. Any helpful suggestions > > are appreciated. > > No, I don't think you're happy. And I'm sorry if it felt like a > complaint, it wasn't meant to be---I had plenty of other patches > committed by either you or Stefan or Anthony, so I cannot really > complain about anything. :) > > The problem is that we have lots of patches that are not ready posted > too early without really following comments. These patches consume a > huge amount of review bandwidth. And more often than not are never > committed because people disappear when they are almost ready. This is due to growth. QEMU is attracting new contributors all the time. Their new features need more integration help not just because the contributors are new the QEMU codebase, but also because the features stretch the boundaries of what QEMU is designed for. I'd rather that RFC series are posted and slowly digested by the community than the alternatives, which are throwing "finished" code over the wall without prior discussion (and the contributor is faced with big change requests from the community, gets frustrated because they thought it was done, and leaves) or simply keeping code out of the QEMU source tree altogether. > At the same time, patches that are almost ready from the beginning, tend > to fall through the cracks. It is not exclusive to the block layer, see > for example Alberto Garcia's serial port patches. We need more reviewers. I've noticed Eric Blake doing a lot of good code review over the past months. When people review code it frees up maintainers to spend more time applying patches. Stefan
diff --git a/block/mirror.c b/block/mirror.c index 82abc2f..0fc140a 100644 --- a/block/mirror.c +++ b/block/mirror.c @@ -87,6 +87,9 @@ static void mirror_iteration_done(MirrorOp *op) cluster_num = op->sector_num / s->granularity; nb_chunks = op->nb_sectors / s->granularity; bitmap_clear(s->in_flight_bitmap, cluster_num, nb_chunks); + if (s->cow_bitmap) { + bitmap_set(s->cow_bitmap, cluster_num, nb_chunks); + } trace_mirror_iteration_done(s, op->sector_num, op->nb_sectors); g_slice_free(MirrorOp, op); @@ -217,9 +220,6 @@ static void coroutine_fn mirror_iteration(MirrorBlockJob *s) /* We have enough free space to copy these sectors. */ bitmap_set(s->in_flight_bitmap, next_cluster, added_chunks); - if (s->cow_bitmap) { - bitmap_set(s->cow_bitmap, next_cluster, added_chunks); - } nb_sectors += added_sectors; nb_chunks += added_chunks;