Am 05.05.2015 um 15:07 hat Paolo Bonzini geschrieben:
>
>
> On 05/05/2015 15:03, Kevin Wolf wrote:
> > > Yes, the SCSI command WRITE SAME with UNMAP = 1 (not coincidentially :))
> > > calls discard too. Who knows what the guest used it for...
> > >
> > > However, write zeroes doesn't go through
On 05/05/2015 15:03, Kevin Wolf wrote:
> > Yes, the SCSI command WRITE SAME with UNMAP = 1 (not coincidentially :))
> > calls discard too. Who knows what the guest used it for...
> >
> > However, write zeroes doesn't go through bdrv_co_discard, does it?
>
> Initially I expected that it does, b
Am 05.05.2015 um 13:49 hat Paolo Bonzini geschrieben:
>
>
> On 05/05/2015 13:48, Kevin Wolf wrote:
> > It depends. In its basic form, bdrv_discard() just means "I don't care
> > about the data any more". Then clearing the dirty bitmap is correct.
> >
> > The content is only important if the call
On Tue, 05/05 13:48, Kevin Wolf wrote:
> Am 05.05.2015 um 12:27 hat Fam Zheng geschrieben:
> > On Tue, 05/05 12:13, Paolo Bonzini wrote:
> > >
> > >
> > > On 05/05/2015 09:36, Fam Zheng wrote:
> > > I don't think this commit is relevant. The bug is caused by
> > > bdrv_co_discard clearing the bi
On 05/05/2015 13:49, Paolo Bonzini wrote:
>
>
> On 05/05/2015 13:48, Kevin Wolf wrote:
>> It depends. In its basic form, bdrv_discard() just means "I don't care
>> about the data any more". Then clearing the dirty bitmap is correct.
>>
>> The content is only important if the caller used discard
On 05/05/2015 13:48, Kevin Wolf wrote:
> It depends. In its basic form, bdrv_discard() just means "I don't care
> about the data any more". Then clearing the dirty bitmap is correct.
>
> The content is only important if the caller used discard to write zeros
> because can_write_zeroes_with_unmap
Am 05.05.2015 um 12:27 hat Fam Zheng geschrieben:
> On Tue, 05/05 12:13, Paolo Bonzini wrote:
> >
> >
> > On 05/05/2015 09:36, Fam Zheng wrote:
> > I don't think this commit is relevant. The bug is caused by
> > bdrv_co_discard clearing the bitmap (which is not supported during
> > iteration, an
On Tue, 05/05 12:13, Paolo Bonzini wrote:
>
>
> On 05/05/2015 09:36, Fam Zheng wrote:
> I don't think this commit is relevant. The bug is caused by
> bdrv_co_discard clearing the bitmap (which is not supported during
> iteration, and is caught by the assertion). That bdrv_reset_dirty is
> not r
On 05/05/2015 09:36, Fam Zheng wrote:
> Since the gdb output is suggesting 1.5.3, it's worth to trying 2.3 which has
> this:
>
> commit c4237dfa635900e4d1cdc6038d5efe3507f45f0c
> Author: Vladimir Sementsov-Ogievskiy
> Date: Thu Nov 27 12:40:46 2014 +0300
>
> block: fix sp
On Thu, 04/30 17:50, Paolo Bonzini wrote:
> John, Fam,
>
> I got this report offlist. This happens if a bit in the hbitmap is
> cleared and the HBitmap has _not_ yet reached the bit. See this comment
> in include/qemu/hbitmap.h:
>
> * Resetting bits before the current
> * position of the iter
On 30/04/2015 17:50, Paolo Bonzini wrote:
> John, Fam,
>
> I got this report offlist. This happens if a bit in the hbitmap is
> cleared and the HBitmap has _not_ yet reached the bit. See this comment
> in include/qemu/hbitmap.h:
>
> * Resetting bits before the current
> * position of the it
John, Fam,
I got this report offlist. This happens if a bit in the hbitmap is
cleared and the HBitmap has _not_ yet reached the bit. See this comment
in include/qemu/hbitmap.h:
* Resetting bits before the current
* position of the iterator is also okay. However, concurrent
* resetting of bi
12 matches
Mail list logo
