All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH] [RFC] qemu-upstream: add discard support for xen_disk
Date: Fri, 17 Jan 2014 16:29:30 +0100	[thread overview]
Message-ID: <20140117152930.GA13324@aepfle.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1401171443080.21510@kaball.uk.xensource.com>

On Fri, Jan 17, Stefano Stabellini wrote:

> On Thu, 9 Jan 2014, Olaf Hering wrote:
> > The discard support is enabled unconditionally. But it would be worth to
> > have a knob to disable it in case the backing file was intentionally
> > created non-sparse to avoid fragmentation.
> > How could this be knob be passed from domU.cfg:disk=[] to the actual
> > qemu process?
> 
> It would need to be on xenstore, because that is the only per-disk
> interface xen_disk is listening to.

I figured that out. There are already script=, backend= and other knobs.
I will see how to add a discard=on|off to libxl and write that to the
xenstore backend node so qemu can get it from there.
What property name do you suggest? I have something like
"toolstack-option-discard" in mind.

> > blkfront_setup_discard should check for "qdisk" instead of (, or in
> > addition to?) "file" to actually make use of this new feature.
> 
> Why? I don't think that would be correct: if the feature is advertised
> on xenstore by the backend (feature-discard) then blkfront can/should
> use it. If it is not present then it is not going to use it.
> Let's not complicate things further.

blockfront is broken:
http://lists.xenproject.org/archives/html/xen-devel/2014-01/msg00988.html


> > +++ b/hw/block/xen_disk.c
> > @@ -68,6 +68,8 @@ struct ioreq {
> >      int                 presync;
> >      int                 postsync;
> >      uint8_t             mapped;
> > +    int64_t             sector_num;
> > +    int                 nb_sectors;
> 
> You have access to the original request via req, I don't think you need
> these two fields, do you?

I will double check if thats doable.

Thanks,

Olaf

  reply	other threads:[~2014-01-17 15:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 22:01 [PATCH] [RFC] qemu-upstream: add discard support for xen_disk Olaf Hering
2014-01-10 10:02 ` Ian Campbell
2014-01-17 15:14 ` Stefano Stabellini
2014-01-17 15:29   ` Olaf Hering [this message]
2014-01-17 15:33     ` Stefano Stabellini
2014-01-17 15:38       ` Olaf Hering
2014-01-17 15:43         ` Stefano Stabellini
2014-01-17 16:06           ` Olaf Hering
2014-01-17 16:14             ` Stefano Stabellini
2014-01-17 16:19               ` Olaf Hering
2014-01-17 15:43         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140117152930.GA13324@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.