On 08.05.2015 12:08, Kevin Wolf wrote:
Am 07.05.2015 um 16:50 hat Paolo Bonzini geschrieben:
On 07/05/2015 16:34, Kevin Wolf wrote:
Am 07.05.2015 um 16:16 hat Paolo Bonzini geschrieben:
On 07/05/2015 16:07, Kevin Wolf wrote:
This is not right for two reasons: The first is that this is
BlockB
On 08/05/2015 12:34, Kevin Wolf wrote:
> Am 08.05.2015 um 12:16 hat Paolo Bonzini geschrieben:
>> On 08/05/2015 12:08, Kevin Wolf wrote:
>>> If so, the commands seem to be hopelessly underspecified, especially
>>> with respect to error conditions. And where it says something about
>>> errors, it
Am 08.05.2015 um 12:16 hat Paolo Bonzini geschrieben:
> On 08/05/2015 12:08, Kevin Wolf wrote:
> > If so, the commands seem to be hopelessly underspecified, especially
> > with respect to error conditions. And where it says something about
> > errors, it doesn't make sense: The server is forbidden
On 08/05/2015 12:08, Kevin Wolf wrote:
> Actually, considering all the information in this thread, I'm inclined
> that we should change both sides. qemu-nbd because ENOSPC might be what
> clients expect by analogy with Linux block devices, even if the
> behaviour for accesses beyond the device si
Am 07.05.2015 um 16:50 hat Paolo Bonzini geschrieben:
> On 07/05/2015 16:34, Kevin Wolf wrote:
> > Am 07.05.2015 um 16:16 hat Paolo Bonzini geschrieben:
> >>
> >>
> >> On 07/05/2015 16:07, Kevin Wolf wrote:
> >>> This is not right for two reasons: The first is that this is
> >>> BlockBackend code
>
On 07/05/2015 16:34, Kevin Wolf wrote:
> Am 07.05.2015 um 16:16 hat Paolo Bonzini geschrieben:
>>
>>
>> On 07/05/2015 16:07, Kevin Wolf wrote:
>>> This is not right for two reasons: The first is that this is
>>> BlockBackend code
>>
>> I think it would take effect for the qemu-nbd case though.
>
Am 07.05.2015 um 16:16 hat Paolo Bonzini geschrieben:
>
>
> On 07/05/2015 16:07, Kevin Wolf wrote:
> > This is not right for two reasons: The first is that this is
> > BlockBackend code
>
> I think it would take effect for the qemu-nbd case though.
Oh, you want to change the server code rather
On 07/05/2015 16:07, Kevin Wolf wrote:
> This is not right for two reasons: The first is that this is
> BlockBackend code
I think it would take effect for the qemu-nbd case though.
> and it wouldn't even take effect for the qcow2 case
> where we're writing past EOF only on the protocol layer. T
Am 07.05.2015 um 15:55 hat Paolo Bonzini geschrieben:
>
>
> On 07/05/2015 15:20, Kevin Wolf wrote:
> > > Does ENOSPC over LVM (dm-linear) work at all, and who generates the
> > > ENOSPC there?
> >
> > The LVM use case is what oVirt uses, so I'm pretty sure that it works.
> > I'm now sure who gene
On 07/05/2015 15:20, Kevin Wolf wrote:
> > Does ENOSPC over LVM (dm-linear) work at all, and who generates the
> > ENOSPC there?
>
> The LVM use case is what oVirt uses, so I'm pretty sure that it works.
> I'm now sure who generates the ENOSPC, but it's not qemu anyway. If I
> had to guess, I'd s
Am 07.05.2015 um 14:47 hat Paolo Bonzini geschrieben:
>
>
> On 07/05/2015 14:29, Kevin Wolf wrote:
> > > No, it shouldn't indeed.
> > >
> > > Could alloc_clusters_noref do bdrv_truncate and return ENOSPC if it
> > > fails? That's how for example qcow and vhdx work. vdi has the same
> > > probl
On 07/05/2015 14:29, Kevin Wolf wrote:
> > No, it shouldn't indeed.
> >
> > Could alloc_clusters_noref do bdrv_truncate and return ENOSPC if it
> > fails? That's how for example qcow and vhdx work. vdi has the same
> > problem.
>
> If you want NBD to return -ENOSPC for writes after EOF, chang
Am 07.05.2015 um 14:20 hat Paolo Bonzini geschrieben:
>
>
> On 06/05/2015 19:23, Max Reitz wrote:
> > The guest sees whatever has been written into reply->error, and that
> > field hasn't been written by this function in that case. It has been
> > written by nbd_receive_reply() in nbd.c, and that
On 06/05/2015 19:23, Max Reitz wrote:
> The guest sees whatever has been written into reply->error, and that
> field hasn't been written by this function in that case. It has been
> written by nbd_receive_reply() in nbd.c, and that value comes directly
> from the server. In case of qemu-nbd being
On 06.05.2015 18:47, Paolo Bonzini wrote:
On 06/05/2015 18:37, Max Reitz wrote:
Because qcow2 tries to write beyond the end of the file; the NBD client
implementation passes that on to the server, and the server simply
reports an error (which the NBD client turns into EIO).
Where?
qemu_c
On 06/05/2015 18:37, Max Reitz wrote:
> Because qcow2 tries to write beyond the end of the file; the NBD client
> implementation passes that on to the server, and the server simply
> reports an error (which the NBD client turns into EIO).
Where?
qemu_coroutine_yield();
*reply = s->reply
On 06.05.2015 18:20, Paolo Bonzini wrote:
On 06/05/2015 18:12, Max Reitz wrote:
I very much think it would be worth fixing, if there wasn't the problem
with legitimate use cases throwing unnecessary warnings.
Right.
I remember having a discussion with Kevin about this series (v1)
regarding q
On 06/05/2015 18:12, Max Reitz wrote:
> I very much think it would be worth fixing, if there wasn't the problem
> with legitimate use cases throwing unnecessary warnings.
Right.
> I remember having a discussion with Kevin about this series (v1)
> regarding qcow2 on LVM; I think my point was tha
On 06.05.2015 17:30, Paolo Bonzini wrote:
On 06/05/2015 15:04, Max Reitz wrote:
Introducing a warning for a normal QEMU invocation is a bit weird.
What is the point of this series? Were users confused that they hit
ENOSPC?
Users were confused when exporting a qcow2 image using nbd-server
ins
On 06/05/2015 15:04, Max Reitz wrote:
>>
>> Introducing a warning for a normal QEMU invocation is a bit weird.
>>
>> What is the point of this series? Were users confused that they hit
>> ENOSPC?
>
> Users were confused when exporting a qcow2 image using nbd-server
> instead of qemu-img, and th
On 05.05.2015 11:46, Stefan Hajnoczi wrote:
On Thu, Mar 19, 2015 at 03:03:18PM -0400, Max Reitz wrote:
Some image formats (e.g. qcow2) require the underlying file to grow on
write accesses, but this is in fact not supported by all protocols (e.g.
nbd does not). If such a format requiring file gr
On Thu, Mar 19, 2015 at 03:03:18PM -0400, Max Reitz wrote:
> Some image formats (e.g. qcow2) require the underlying file to grow on
> write accesses, but this is in fact not supported by all protocols (e.g.
> nbd does not). If such a format requiring file growth is used
> non-read-only over a proto
22 matches
Mail list logo
