All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Resizing block devices live?
Date: Tue, 18 Dec 2012 09:37:56 -0500	[thread overview]
Message-ID: <20121218143756.GA24713@phenom.dumpdata.com> (raw)
In-Reply-To: <CAFLBxZZk9=dtnE+1ro-ZCN-6SN5JicQdH7nmejVvJgLmiSNzJg@mail.gmail.com>

On Tue, Dec 18, 2012 at 02:06:56PM +0000, George Dunlap wrote:
> On Tue, Dec 18, 2012 at 1:58 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
> 
> > On Tue, 2012-12-18 at 13:52 +0000, George Dunlap wrote:
> > > One of the requests from the xenorg.uservoice.com page that had a
> > > moderate amount of interest was to allow block devices to be resized.
> > > There's a description here:
> > >
> > >
> > https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3140313-implement-block-device-resize
> > >
> > >
> > > I have no idea what this would take -- can anyone comment?
> >
> > Doesn't that already work? I thought this was patch in the PV block
> > drivers ages ago...
> >
> > Yes, http://wiki.xen.org/wiki/XenParavirtOps lists it under 2.6.36.
> >
> > Maybe this is a missing feature of (lib)xl vs xend?
> >
> 
> "xm help" doesn't show a "block-resize" command, nor does grepping through
> tools for "resize" turn up anything.
> 
> Would someone be willing to do some investigation into whether such a
> command is implemented in the protocol, and what it would take to get a "xm
> block-resize" command working?  (Not necessarily do it, but have an idea
> what probably needs to be done.)

Looking at the history it looks to be:

1fa73be6be65028a7543bba8f14474b42e064a1b which is


commit 1fa73be6be65028a7543bba8f14474b42e064a1b
Author: K. Y. Srinivasan <ksrinivasan@novell.com>
Date:   Thu Mar 11 13:42:26 2010 -0800

    xen/front: Propagate changed size of VBDs
    
    Support dynamic resizing of virtual block devices. This patch supports
    both file backed block devices as well as physical devices that can be
    dynamically resized on the host side.
    
    Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 60006b7..f47b096 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -930,9 +930,24 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned int binfo;
 	int err;
 
-	if ((info->connected == BLKIF_STATE_CONNECTED) ||
-	    (info->connected == BLKIF_STATE_SUSPENDED) )
+	switch (info->connected) {
+	case BLKIF_STATE_CONNECTED:
+		/*
+		 * Potentially, the back-end may be signalling
+		 * a capacity change; update the capacity.
+		 */
+		err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+				   "sectors", "%Lu", &sectors);
+		if (XENBUS_EXIST_ERR(err))
+			return;
+		printk(KERN_INFO "Setting capacity to %Lu\n",
+		       sectors);
+		set_capacity(info->gd, sectors);
+
+		/* fall through */
+	case BLKIF_STATE_SUSPENDED:
 		return;
+	}
 
 	dev_dbg(&info->xbdev->dev, "%s:%s.\n",
 		__func__, info->xbdev->otherend);

So it should be altering the 'sectors' value and just writting 
the backend state from XenbusStateConnected to XenbusStateConnected.

  parent reply	other threads:[~2012-12-18 14:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18 13:52 Resizing block devices live? George Dunlap
2012-12-18 13:58 ` Ian Campbell
2012-12-18 14:06   ` George Dunlap
2012-12-18 14:34     ` Jan Beulich
2012-12-18 14:37     ` Konrad Rzeszutek Wilk [this message]
2012-12-18 14:43       ` Ian Campbell
2012-12-18 14:51       ` Jan Beulich
2012-12-18 15:58         ` Ian Campbell
     [not found]     ` <CAFLBxZazULnr8PRN_4fshUAmuohyn2o4AcqpohdjxbmDnVStGQ@mail.gmail.com>
2012-12-18 15:50       ` George Dunlap
2012-12-18 20:23     ` Pasi Kärkkäinen

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=20121218143756.GA24713@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=roger.pau@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.