Am 10.10.2017 um 08:58 hat Markus Armbruster geschrieben:
> Doug Gale writes:
>
> > I used exclamations as a concise way of indicating that the driver did
> > something nonsensical, or horribly invalid, like something likely to
> > cause a memory corruption, trying to start the controller with a
On 09/10/2017 19:27, Vladimir Sementsov-Ogievskiy wrote:
>
> +int ret = nbd_co_do_receive_one_chunk(s, handle, only_structured,
> + &request_ret, qiov, payload);
> +
> +if (ret < 0) {
> +s->quit = true;
> +} else {
> +/* For asse
Am 13.09.2017 um 20:18 hat Max Reitz geschrieben:
> Drainined a BDS child may lead to both the original BDS and/or its other
> children being deleted (e.g. if the original BDS represents a block
> job). We should prepare for this in both bdrv_drain_recurse() and
> bdrv_drained_begin() by monitorin
On Mon, Oct 09, 2017 at 02:18:10PM -0500, Eric Blake wrote:
> [adding Dan for a qio question - search for your name below]
>
> On 10/09/2017 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> > Get rid of calculating structure fields offsets by hand and set_cork,
> > rename nbd_co_send_reply to nbd_c
On 10/10/2017 10:40, Daniel P. Berrange wrote:
> The I/O channels code does not make guarantees wrt concurrent usage of
> threads or coroutines. It is the callers responsibility to avoid any
> concurrent usage for all APIs. With coroutines you are at least avoiding
> the danger of corrupting memory
Am 13.09.2017 um 20:18 hat Max Reitz geschrieben:
> In order to talk to the source BDS (and maybe in the future to the
> target BDS as well) directly, we need to convert our existing AIO
> requests into coroutine I/O requests.
>
> Signed-off-by: Max Reitz
Please follow through with it and add a
Am 13.09.2017 um 20:19 hat Max Reitz geschrieben:
> With this, the mirror_top_bs is no longer just a technically required
> node in the BDS graph but actually represents the block job operation.
>
> Signed-off-by: Max Reitz
> ---
> block/mirror.c | 18 ++
> 1 file changed, 10 ins
Am 13.09.2017 um 20:19 hat Max Reitz geschrieben:
> Regarding the source BDS, the mirror BDS is arguably a filter node.
> Therefore, the source BDS should be its "file" child.
>
> Signed-off-by: Max Reitz
TODO: Justification why this doesn't break things like
bdrv_is_allocated_above() that itera
Am 13.09.2017 um 20:19 hat Max Reitz geschrieben:
> The owner of the mirror BDS might retire its write permission; but there
> may still be pending mirror operations so the mirror BDS cannot
> necessarily retire its write permission for its child then.
>
> Signed-off-by: Max Reitz
I'm confused.
Am 18.09.2017 um 18:26 hat Max Reitz geschrieben:
> On 2017-09-18 12:06, Stefan Hajnoczi wrote:
> > On Sat, Sep 16, 2017 at 03:58:01PM +0200, Max Reitz wrote:
> >> On 2017-09-14 17:57, Stefan Hajnoczi wrote:
> >>> On Wed, Sep 13, 2017 at 08:19:07PM +0200, Max Reitz wrote:
> This patch implemen
Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
> There are patches floating around to add NBD_CMD_BLOCK_STATUS,
> but NBD wants to report status on byte granularity (even if the
> reporting will probably be naturally aligned to sectors or even
> much higher levels). I've therefore started the
We do not reopen lock_fd on bdrv_reopen which leads to problems on
reopen image RO. So, lets make lock_fd be always RO.
This is correct, because qemu_lock_fd always called with exclusive=false
on lock_fd.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Hi all!
We've faced the following problem
Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
> Not all callers care about which BDS owns the mapping for a given
> range of the file. This patch merely simplifies the callers by
> consolidating the logic in the common call point, while guaranteeing
> a non-NULL file to all the driver callbac
Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
> We are gradually converting to byte-based interfaces, as they are
> easier to reason about than sector-based. Convert another internal
> function (no semantic change), and rename it to is_zero() in the
> process.
>
> Signed-off-by: Eric Blake
09.10.2017 20:27, Vladimir Sementsov-Ogievskiy wrote:
Minimal implementation: for structured error only error_report error
message.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/nbd.h | 6 +
block/nbd-client.c | 358
nb
On 10/10/2017 08:59 AM, Kevin Wolf wrote:
> Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
>> Not all callers care about which BDS owns the mapping for a given
>> range of the file. This patch merely simplifies the callers by
>> consolidating the logic in the common call point, while guarantee
On 10/10/2017 07:58 AM, Kevin Wolf wrote:
> Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
>> There are patches floating around to add NBD_CMD_BLOCK_STATUS,
>> but NBD wants to report status on byte granularity (even if the
>> reporting will probably be naturally aligned to sectors or even
>> m
Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
> We are gradually moving away from sector-based interfaces, towards
> byte-based. In the common case, allocation is unlikely to ever use
> values that are not naturally sector-aligned, but it is possible
> that byte-based values will let us be mo
On 10/10/2017 09:15 AM, Kevin Wolf wrote:
> Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
>> We are gradually converting to byte-based interfaces, as they are
>> easier to reason about than sector-based. Convert another internal
>> function (no semantic change), and rename it to is_zero() in
10.10.2017 11:02, Paolo Bonzini wrote:
On 09/10/2017 19:27, Vladimir Sementsov-Ogievskiy wrote:
+int ret = nbd_co_do_receive_one_chunk(s, handle, only_structured,
+ &request_ret, qiov, payload);
+
+if (ret < 0) {
+s->quit = true;
+} el
On 10/10/2017 16:55, Vladimir Sementsov-Ogievskiy wrote:
> Hmm, would it be simpler just pass a function pointer, which should be
> called on each loop iteration?
> So, we will return to one common func nbd_co_receive_reply, but with two
> additional parameters: func and opaque?
Function pointers
On 10/10/2017 09:46 AM, Kevin Wolf wrote:
> Am 04.10.2017 um 04:00 hat Eric Blake geschrieben:
>> We are gradually moving away from sector-based interfaces, towards
>> byte-based. In the common case, allocation is unlikely to ever use
>> values that are not naturally sector-aligned, but it is poss
On 10/10/2017 08:42 AM, Vladimir Sementsov-Ogievskiy wrote:
> We do not reopen lock_fd on bdrv_reopen which leads to problems on
> reopen image RO. So, lets make lock_fd be always RO.
> This is correct, because qemu_lock_fd always called with exclusive=false
> on lock_fd.
How is that correct? fil
On 10/10/2017 09:43 AM, Eric Blake wrote:
>>> ---
>>> v5: use second label for cleaner exit logic [John], use local_pnum
>
>>> @@ -1811,16 +1811,19 @@ static int64_t coroutine_fn
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>> int64_t total_sectors;
>>> int64_t n;
>>> int64
On 10/10/2017 03:00 PM, Eric Blake wrote:
> On 10/10/2017 09:43 AM, Eric Blake wrote:
>
---
v5: use second label for cleaner exit logic [John], use local_pnum
>>
@@ -1811,16 +1811,19 @@ static int64_t coroutine_fn
bdrv_co_get_block_status(BlockDriverState *bs,
int6
On 10/10/2017 09:50 PM, Eric Blake wrote:
> On 10/10/2017 08:42 AM, Vladimir Sementsov-Ogievskiy wrote:
>> We do not reopen lock_fd on bdrv_reopen which leads to problems on
>> reopen image RO. So, lets make lock_fd be always RO.
>> This is correct, because qemu_lock_fd always called with exclusive
On 10/10/2017 02:30 PM, Denis V. Lunev wrote:
> On 10/10/2017 09:50 PM, Eric Blake wrote:
>> On 10/10/2017 08:42 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> We do not reopen lock_fd on bdrv_reopen which leads to problems on
>>> reopen image RO. So, lets make lock_fd be always RO.
>>> This is correc
27 matches
Mail list logo