19.02.2022 06:04, Nikta Lapshin wrote:
On 2/15/22 20:53, Vladimir Sementsov-Ogievskiy wrote:
We have too much logic to simply check that bitmaps are of the same
size. Let's just define that hbitmap_merge() and
bdrv_dirty_bitmap_merge_internal() require their argument bitmaps be of
same size,
Only qcow2 driver supports vmstate.
In qcow2 these requests go through .bdrv_co_p{read,write}v_part
handlers.
So, let's do our basic check for the request on vmstate generic
handlers.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
block/io.c | 18 --
1
Add interface which help to do fleecing read. To be used in the next
commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/copy-before-write.h | 5 ++
block/copy-before-write.c | 103 +-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git
24.05.2021 20:34, John Snow wrote:
On 5/24/21 9:32 AM, Stefan Hajnoczi wrote:
On Sat, May 22, 2021 at 12:32:00AM +0530, Niteesh G. S. wrote:
Welcome Niteesh :) I look forward to working with you this summer.
By end of this summer, I would like to get a basic TUI with some desirable
features
15.05.2021 00:53, Emanuele Giuseppe Esposito wrote:
we want to get from shres here, after possible call to block_copy_task_shrink(),
as task->bytes may be reduced.
Ah right, I missed that. So I guess if we want the caller to protect
co-shared-resource, get_from_shres stays where it is, and
14.05.2021 20:28, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 17:30, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because
There are only two drivers supporting vmstate: qcow2 and sheepdog.
Sheepdog is deprecated. In qcow2 these requests go through
.bdrv_co_p{read,write}v_part handlers.
So, let's do our basic check for the request on vmstate generic
handlers.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
These functions are called only from bdrv_reopen_multiple() in block.c.
No reason to publish them.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
include/block/block.h | 4
block.c | 13 +
2 files changed, 9
There are only two drivers supporting vmstate: qcow2 and sheepdog.
Sheepdog is deprecated. In qcow2 these requests go through
.bdrv_co_p{read,write}v_part handlers.
So, let's do our basic check for the request on vmstate generic
handlers.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
18.03.2021 02:23, John Snow wrote:
On 3/9/21 7:16 PM, ChangLimin wrote:
Since Linux 5.10, write zeros to a multipath device using
ioctl(fd, BLKZEROOUT, range) with cache none or directsync return -EBUSY
permanently.
When do we get -EINVAL? Both of the commits referenced below don't
These functions are called only from bdrv_reopen_multiple() in block.c.
No reason to publish them.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Kevin Wolf
---
include/block/block.h | 4
block.c | 13 +
2 files changed, 9
We are generally moving to int64_t for both offset and bytes parameters
on all io paths.
Main motivation is realization of 64-bit write_zeroes operation for
fast zeroing large disk chunks, up to the whole disk.
We chose signed type, to be consistent with off_t (which is signed) and
with
These functions are called only from bdrv_reopen_multiple() in block.c.
No reason to publish them.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block.h | 4
block.c | 13 +
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git
Hi all!
I'm about this:
"A server SHOULD try to minimize the number of chunks sent in a reply,
but MUST NOT mark a chunk as final if there is still a possibility of
detecting an error before transmission of that chunk completes"
What do we mean by "possibility"? Formally, such possibility
16 matches
Mail list logo