Re: [Qemu-block] [Qemu-devel] [PATCH for-2.12?] m25p80: Correct the at25128a/at25256a eeproms size

On Mon, Apr 16, 2018 at 9:05 AM, mar.krzeminski wrote: > W dniu 15.04.2018 o 22:31, Philippe Mathieu-Daudé pisze: >> >> >From the datasheet (3368J–SEEPR) description: >> The AT25128A/256A provides 131,072/262,144 bits of serial >> electrically-erasable

[Qemu-block] [PATCH 9/9] iotests: Add test for COR across nodes

COR across nodes (that is, you have some filter node between the actually COR target and the node that performs the COR) cannot reliably work together with the permission system when there is no explicit COR node that can request the WRITE_UNCHANGED permission for its child. This is because COR

[Qemu-block] [PATCH 7/9] iotests: Clean up wrap image in 197

Signed-off-by: Max Reitz --- tests/qemu-iotests/197 | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/qemu-iotests/197 b/tests/qemu-iotests/197 index 5e869fe2b7..3ae4975eec 100755 --- a/tests/qemu-iotests/197 +++ b/tests/qemu-iotests/197 @@ -44,6 +44,7 @@ esac

[Qemu-block] [PATCH 5/9] block/quorum: Support BDRV_REQ_WRITE_UNCHANGED

We just need to forward it to quorum's children (except in case of a rewrite because of corruption), but for that we first have to support flags in child requests at all. Signed-off-by: Max Reitz --- block/quorum.c | 19 +-- 1 file changed, 13 insertions(+), 6

[Qemu-block] [PATCH 4/9] block: Set BDRV_REQ_WRITE_UNCHANGED for COR writes

Signed-off-by: Max Reitz --- block/io.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/block/io.c b/block/io.c index 134b2a498f..fada4efbf3 100644 --- a/block/io.c +++ b/block/io.c @@ -1115,13 +1115,15 @@ static int coroutine_fn

[Qemu-block] [PATCH 0/9] block: Add COR filter driver

In our quest to... (Oh, man, I always struggle with writing cover letters. But rarely have I become stuck so early on.) Orthogonalize? the block layer (that is, turn hard-coded special options into independent data processing nodes you can put anywhere in your data flow graph), this series adds

[Qemu-block] [PATCH 8/9] iotests: Copy 197 for COR filter driver

iotest 197 tests copy-on-read using the (now old) copy-on-read flag. Copy it to 215 and modify it to use the COR filter driver instead. Signed-off-by: Max Reitz --- tests/qemu-iotests/215 | 120 + tests/qemu-iotests/215.out |

[Qemu-block] [PATCH 6/9] block: Support BDRV_REQ_WRITE_UNCHANGED in filters

Update the rest of the filter drivers to support BDRV_REQ_WRITE_UNCHANGED. They already forward write request flags to their children, so we just have to announce support for it. This patch does not cover the replication driver because that currently does not support flags at all, and because it

[Qemu-block] [PATCH 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag

This flag signifies that a write request will not change the visible disk content. With this flag set, it is sufficient to have the BLK_PERM_WRITE_UNCHANGED permission instead of BLK_PERM_WRITE. Signed-off-by: Max Reitz --- include/block/block.h | 6 +- block/io.c

[Qemu-block] [PATCH 2/9] block: BLK_PERM_WRITE includes ..._UNCHANGED

Currently we never actually check whether the WRITE_UNCHANGED permission has been taken for unchanging writes. But the one check that is commented out checks both WRITE and WRITE_UNCHANGED; and considering that WRITE_UNCHANGED is already documented as being weaker then WRITE, we should probably

[Qemu-block] [PATCH 1/9] block: Add COR filter driver

This adds a simple copy-on-read filter driver. It relies on the already existing COR functionality in the central block layer code, which may be moved here once we no longer need it there. Signed-off-by: Max Reitz --- block/Makefile.objs | 2 +- qapi/block-core.json | 5

Re: [Qemu-block] [PATCH for-2.12?] m25p80: Correct the at25128a/at25256a eeproms size

W dniu 15.04.2018 o 22:31, Philippe Mathieu-Daudé pisze: >From the datasheet (3368J–SEEPR) description: The AT25128A/256A provides 131,072/262,144 bits of serial electrically-erasable programmable read only memory (EEPROM) organized as 16,384/32,768 words of 8 bits each. However

Re: [Qemu-block] [PATCH v2 2/2] docs: Document the new default sizes of the qcow2 caches

On 2018-03-14 09:29, Alberto Garcia wrote: > We have just reduced the refcount cache size to the minimum unless > the user explicitly requests a larger one, so we have to update the > documentation to reflect this change. > > Signed-off-by: Alberto Garcia > Reviewed-by: Eric

Re: [Qemu-block] [PATCH v2 1/2] qcow2: Give the refcount cache the minimum possible size by default

On 2018-03-14 09:29, Alberto Garcia wrote: > The L2 and refcount caches have default sizes that can be overridden > using the l2-cache-size and refcount-cache-size (an additional > parameter named cache-size sets the combined size of both caches). > > Unless forced by one of the aforementioned

Re: [Qemu-block] [PULL 0/2] Block patches for 2.12.0-rc4

On 16 April 2018 at 13:38, Max Reitz wrote: > The following changes since commit ae2b1b4e1bb89ea949446597c8776255da0a79d3: > > Merge remote-tracking branch > 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2018-04-16 > 10:11:17 +0100) > > are available in the

Re: [Qemu-block] [RFC] Intermediate block mirroring

On 2018-04-16 16:59, Alberto Garcia wrote: > On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote: >> On 2018-04-12 19:07, Alberto Garcia wrote: >>> Hello, >>> >>> I mentioned this some time ago, but I'd like to retake it now: I'm >>> checking how to copy arbitrary nodes on a backing chain, so if

Re: [Qemu-block] [RFC] Intermediate block mirroring

On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote: > On 2018-04-12 19:07, Alberto Garcia wrote: >> Hello, >> >> I mentioned this some time ago, but I'd like to retake it now: I'm >> checking how to copy arbitrary nodes on a backing chain, so if I have >> e.g. >> >>[A] <- [B] <- [C] <- [D]

Re: [Qemu-block] [PATCH v2 1/2] qcow2: Give the refcount cache the minimum possible size by default

On Mon 16 Apr 2018 04:05:21 PM CEST, Max Reitz wrote: >> Refcount entries are used to reference host clusters, and host >> clusters are always(*) allocated sequentially, so caching refcount >> blocks doesn't do much. You're always loading the same refcount block >> until it's full, then you move

Re: [Qemu-block] [PATCH v2 1/2] qcow2: Give the refcount cache the minimum possible size by default

On 2018-04-16 15:56, Alberto Garcia wrote: > On Fri 13 Apr 2018 05:00:48 PM CEST, Max Reitz wrote: >> On 2018-03-14 09:29, Alberto Garcia wrote: >>> The L2 and refcount caches have default sizes that can be overridden >>> using the l2-cache-size and refcount-cache-size (an additional >>> parameter

Re: [Qemu-block] [PATCH v2 1/2] qcow2: Give the refcount cache the minimum possible size by default

On Fri 13 Apr 2018 05:00:48 PM CEST, Max Reitz wrote: > On 2018-03-14 09:29, Alberto Garcia wrote: >> The L2 and refcount caches have default sizes that can be overridden >> using the l2-cache-size and refcount-cache-size (an additional >> parameter named cache-size sets the combined size of both

[Qemu-block] [PULL 1/2] qcow2: try load bitmaps only once

From: Vladimir Sementsov-Ogievskiy Checking reopen by existence of some bitmaps is wrong, as it may be some other bitmaps, or on the other hand, user may remove bitmaps. This criteria is bad. To simplify things and make behavior more predictable let's just add a flag to

[Qemu-block] [PULL 2/2] iotests: fix 169

From: Vladimir Sementsov-Ogievskiy Improve and fix 169: - use MIGRATION events instead of RESUME - make a TODO: enable dirty-bitmaps capability for offline case - recreate vm_b without -incoming near test end This (likely) fixes racy faults at least of the

[Qemu-block] [PULL 0/2] Block patches for 2.12.0-rc4

The following changes since commit ae2b1b4e1bb89ea949446597c8776255da0a79d3: Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2018-04-16 10:11:17 +0100) are available in the Git repository at: git://github.com/XanClic/qemu.git

Re: [Qemu-block] [PATCH 0/2] iotests: Skip 181 and 201 without userfaultfd

On 2018-04-06 17:17, Max Reitz wrote: > My non-Fedora testing system does not have a kernel with userfaultfd > support which causes 181 and 201 to fail. That is annoying. This > series makes those tests recognize the issue and convert it into a > _notrun. > > > Max Reitz (2): > iotests: Add

[Qemu-block] [PATCH v2 7/7] blockdev: unify block-dirty-bitmap-clear command and transaction action

- use error messages from qmp command, as they are more descriptive - we need not check bs, as block_dirty_bitmap_lookup never returns bs = NULL on success (and if user set bs to be not NULL pointer), so, let's just assert it. Signed-off-by: Vladimir Sementsov-Ogievskiy

[Qemu-block] [PATCH v2 3/7] dirty-bitmap: remove missed bdrv_dirty_bitmap_get_autoload header

Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/block/dirty-bitmap.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h index 1ff8949b1b..c7e910016d 100644 --- a/include/block/dirty-bitmap.h +++

[Qemu-block] [PATCH v2 2/7] dirty-bitmaps: fix comment about dirty_bitmap_mutex

Clarify first two cases and fix Modify -> Any access in third case. Also, drop 'only' from third case, as it a bit confuses, when thinking about case where we modify BdrvDirtyBitmap and access HBitmap. Signed-off-by: Vladimir Sementsov-Ogievskiy ---

[Qemu-block] [PATCH v2 5/7] blockdev: refactor block-dirty-bitmap-clear transaction

bdrv_clear_dirty_bitmap do not fail, so we can call it in transaction commit, avoiding any rollback. After this, bdrv_undo_clear_dirty_bitmap() becomes unused, so, drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/block/block_int.h | 1 -

[Qemu-block] [PATCH v2 4/7] dirty-bitmap: separate unused meta-bitmap related functions

Separate them in the header and clarify needed locking in comments. Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/block/dirty-bitmap.h | 14 +- block/dirty-bitmap.c | 5 + 2 files changed, 14 insertions(+), 5 deletions(-) diff --git

[Qemu-block] [PATCH v2 6/7] block/dirty-bitmap: bdrv_clear_dirty_bitmap: drop unused parameter

Drop parameter "HBitmap **out" which is unused now, all callers set it to NULL. Signed-off-by: Vladimir Sementsov-Ogievskiy --- include/block/block_int.h | 2 +- block/dirty-bitmap.c | 14 +- blockdev.c| 4 ++-- 3 files changed, 8

[Qemu-block] [PATCH v2 1/7] block/dirty-bitmap: add lock to bdrv_enable/disable_dirty_bitmap

Functions write to BdrvDirtyBitmap field, so the should take the lock. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/dirty-bitmap.c | 4 1 file changed, 4 insertions(+) diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c index 967159479d..6c00288fd7

[Qemu-block] [PATCH v2 for-2.13 0/7] Dirty bitmaps fixing and refactoring

v2: 05: drop bdrv_undo_clear_dirty_bitmap(), which becomes unused. Vladimir Sementsov-Ogievskiy (7): block/dirty-bitmap: add lock to bdrv_enable/disable_dirty_bitmap dirty-bitmaps: fix comment about dirty_bitmap_mutex dirty-bitmap: remove missed bdrv_dirty_bitmap_get_autoload header

Re: [Qemu-block] [PATCH 2/4] nbd/server: add nbd_meta_single_query helper

14.04.2018 00:06, John Snow wrote: On 04/13/2018 01:44 PM, Vladimir Sementsov-Ogievskiy wrote: will add, as always, thank you for natural rewording) Hm, I have a question: why do you often use double white-space "  " between sentences? Is it something meaningful? There is some GREAT DEBATE in

Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow listing exports

On Mon, Apr 16, 2018 at 11:53:41AM +0100, Richard W.M. Jones wrote: > On Mon, Apr 16, 2018 at 11:31:18AM +0100, Daniel P. Berrangé wrote: > > Essentially this is abusing the export name as a crude authentication > > token. There are NBD servers that expect NBD_OPT_LIST to always succeeed > > I

Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow listing exports

On Mon, Apr 16, 2018 at 11:31:18AM +0100, Daniel P. Berrangé wrote: > Essentially this is abusing the export name as a crude authentication > token. There are NBD servers that expect NBD_OPT_LIST to always succeeed I guess you mean "NBD clients" ... > when they detect that the new style protocol

Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow listing exports

On Fri, Apr 13, 2018 at 10:26:03PM +0300, Nir Soffer wrote: > When a management application expose images using qemu-nbd, it needs a > secure way to allow temporary access to the disk. Using a random export > name can solve this problem: > >

Re: [Qemu-block] [Qemu-discuss] qemu-img convert stuck

On Mon, Apr 09, 2018 at 10:38:54AM +0300, Benny Zlotnik wrote: > source: qcow2 on NFS > target: raw on NFS Have you tried on a local file system with the same source file contents? Which NFS protocol version is being used? Stefan signature.asc Description: PGP signature