On Sat, Jul 21, 2018 at 12:35 AM Eric Blake wrote:
>
> On 07/20/2018 03:24 AM, Fam Zheng wrote:
> I'm not familiar with /dev/nullb* - is that a typo?
>
> $ ll /dev/nullb*
> ls: cannot access '/dev/nullb*': No such file or directory
You probably have figured out already but just in case: it's kern
On 06/26/2018 09:50 AM, Vladimir Sementsov-Ogievskiy wrote:
> This patch aims to bring the following behavior:
Just as a primer for anyone else reading this email (nobody) who might
not understand the terminology (less than nobody), it might be helpful
to remember that:
-INACTIVATE occurs eithe
On 07/13/2018 06:14 AM, Max Reitz wrote:
Past the end of the source backing file, we memset() buf_old to zero, so
it is clearly easy to use blk_pwrite_zeroes() instead of blk_pwrite()
then.
Signed-off-by: Max Reitz
---
qemu-img.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions
On 07/12/2018 03:32 PM, John Snow wrote:
+++ b/block/gluster.c
@@ -1326,7 +1326,7 @@ static int qemu_gluster_has_zero_init(BlockDriverState
*bs)
* If @start is in a trailing hole or beyond EOF, return -ENXIO.
* If we can't find out, return a negative errno other than -ENXIO.
*
- * (Sha
On 07/10/2018 09:33 AM, Vladimir Sementsov-Ogievskiy wrote:
04.07.2018 14:23, Vladimir Sementsov-Ogievskiy wrote:
This is necessary for efficient block-status export, for clients which
support it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
+static int blockstatus_to_extents(BlockDriver
On 07/09/2018 04:32 AM, Kevin Wolf wrote:
Am 06.07.2018 um 23:20 hat Eric Blake geschrieben:
On 07/06/2018 11:45 AM, Kevin Wolf wrote:
If the virtual disk size isn't aligned to full clusters,
bdrv_co_do_copy_on_readv() may get pnum == 0 before having the full
cluster completed, which will let i
On 06/09/2018 10:32 AM, Vladimir Sementsov-Ogievskiy wrote:
To implement nbd reconnect in further patches, we need to distinguish
error codes, returned by nbd server, from channel errors, to reconnect
only in the latter case.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/nbd-client.c
On 07/20/2018 03:32 PM, Nishanth Aravamudan wrote:
On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's a
different assertion, it might be related based on the call trace.
Just to be clear, this does not happen if you reve
I am seeing another issue pop up, in a different test. Even though it's
a different assertion, it might be related based on the call trace.
Stack trace of thread 276199:
#0 0x03ff8473e274 raise (libc.so.6)
#1 0x03ff847239a8 abort (libc.so.6)
#2 0x03ff847362ce __assert_fail_base (l
On Wed, Jul 18, 2018 at 07:36:28PM -0300, Philippe Mathieu-Daudé wrote:
> Both Python 2.7 and 3 support the same io.StringIO to
> handle unicode strings.
>
> Python 2.6 requires special care, but since 7f2b55443a his
> support was removed. Stop caring, drop the ImportError check.
>
> Use the comm
On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote:
> I am seeing another issue pop up, in a different test. Even though it's a
> different assertion, it might be related based on the call trace.
Just to be clear, this does not happen if you revert the original patch
(i.e., the one you bisected to b
On 07/20/2018 04:24 AM, Fam Zheng wrote:
> On Thu, 07/19 13:57, John Snow wrote:
>> Should we instead modify the test in this case to not attempt to take a
>> lock on a device we know cannot meaningfully store state, or is it your
>> preference to attempt to maintain such a list in the raw drive
On 07/20/2018 03:24 AM, Fam Zheng wrote:
On Thu, 07/19 13:57, John Snow wrote:
Should we instead modify the test in this case to not attempt to take a
lock on a device we know cannot meaningfully store state, or is it your
preference to attempt to maintain such a list in the raw driver itself?
On 07/19/2018 12:57 PM, John Snow wrote:
Should we instead modify the test in this case to not attempt to take a
lock on a device we know cannot meaningfully store state, or is it your
preference to attempt to maintain such a list in the raw driver itself?
I guess we never want QEMU to try to l
On Thu, Jul 19, 2018 at 09:39:35PM +0100, Richard W.M. Jones wrote:
> I did the original work using AFL to fuzz qemu-img and find
> problematic images. From that work Dan & I suggested some fairly low
> limits (10 seconds IIRC). See:
>
> https://bugs.launchpad.net/qemu/+bug/1462944
> https://bug
On Thu, Jul 19, 2018 at 09:50:00PM +0300, Nir Soffer wrote:
> On Mon, Jul 16, 2018 at 11:56 AM Daniel P. Berrangé
> wrote:
> ...
>
> > Recommendation is to run 'qemu-img info' to extract the metadata and sanity
> > check results eg no backing file list, not unreasonable size, etc. When
> > runnin
On Thu, 07/19 13:57, John Snow wrote:
> Should we instead modify the test in this case to not attempt to take a
> lock on a device we know cannot meaningfully store state, or is it your
> preference to attempt to maintain such a list in the raw driver itself?
>
> I guess we never want QEMU to try
17 matches
Mail list logo
