@Jinank I have not started working on this at all, so please go ahead!
Let me know if I can help with testing or anything, we make quite
extensive use of nbd and qcow2 images internally.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
That was also my feeling, so nice to get a confirmation!
Another related thing would be to allow qemu-nbd to write compressed
blocks its backing image - today if you use a qcow2 with compression,
any block which is written to gets uncompressed in the resulting image
and you need to recompress the
It looks like qcow2_write_compressed() has been removed and turned into
a qemu co-routine in qemu 2.8.0 (released in December 2017) to support
live compressed back-ups. Any pointers to start working on this? We
have servers with 128 CPUs and it's very sad to see them compress on a
single CPU and
On Tue, May 10, 2016 at 02:34:18PM -0600, Eric Blake wrote:
> On 05/06/2016 02:45 AM, Quentin Casasnovas wrote:
> > When running fstrim on a filesystem mounted through qemu-nbd with
> > --discard=on, fstrim would fail with I/O errors:
> >
> > $ fstrim /k/spl/ic
On Tue, May 10, 2016 at 05:23:21PM +0100, Alex Bligh wrote:
>
> On 10 May 2016, at 17:04, Quentin Casasnovas
> wrote:
>
> > Alright, I assumed by 'length of an NBD request', the specification was
> > talking about the length of.. well, the request as oppose
On Tue, May 10, 2016 at 05:54:44PM +0200, Quentin Casasnovas wrote:
> On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote:
> > On 05/10/2016 09:41 AM, Alex Bligh wrote:
> > >
> > > On 10 May 2016, at 16:29, Eric Blake wrote:
> > >
> > >> So
On Tue, May 10, 2016 at 04:49:57PM +0100, Alex Bligh wrote:
>
> On 10 May 2016, at 16:45, Quentin Casasnovas
> wrote:
>
> > I'm by no mean an expert in this, but why would the kernel break up those
> > TRIM commands? After all, breaking things up makes sense when
On Tue, May 10, 2016 at 09:46:36AM -0600, Eric Blake wrote:
> On 05/10/2016 09:41 AM, Alex Bligh wrote:
> >
> > On 10 May 2016, at 16:29, Eric Blake wrote:
> >
> >> So the kernel is currently one of the clients that does NOT honor block
> >> sizes, and as such, servers should be prepared for ANY
On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote:
> Eric,
>
> On 10 May 2016, at 16:29, Eric Blake wrote:
> >>> Maybe we should revisit that in the spec, and/or advertise yet another
> >>> block size (since the maximum size for a trim and/or write_zeroes
> >>> request may indeed be diff
at least keep their size proportional to the amount of data
present on them).
Signed-off-by: Quentin Casasnovas
CC: Paolo Bonzini
CC:
CC:
CC:
---
nbd.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/nbd.c b/nbd.c
index b3d9654..e733669 100644
--- a/nbd.c
++
10 matches
Mail list logo
