All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH]: Support dynamic resizing of vbds
@ 2010-03-09 19:56 Ky Srinivasan
  2010-03-09 20:15 ` Pasi Kärkkäinen
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-09 19:56 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

The attached patch supports dynamic resizing of vbds.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>



[-- Attachment #2: xen-vbd-resize --]
[-- Type: application/octet-stream, Size: 4210 bytes --]

Subject: Propagate changed size of VBDs
References: bnc#583677
Patch-mainline: n/a

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>

--- sle11sp1-2010-03-05.orig/drivers/xen/blkback/blkback.c	2010-01-04 13:29:53.000000000 +0100
+++ sle11sp1-2010-03-05/drivers/xen/blkback/blkback.c	2010-03-08 10:33:18.000000000 +0100
@@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
 int blkif_schedule(void *arg)
 {
 	blkif_t *blkif = arg;
+	struct vbd *vbd = &blkif->vbd;
 
 	blkif_get(blkif);
 
@@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
 	while (!kthread_should_stop()) {
 		if (try_to_freeze())
 			continue;
+		if (unlikely(vbd->size != vbd_size(vbd)))
+			vbd_resize(blkif);
 
 		wait_event_interruptible(
 			blkif->wq,
--- sle11sp1-2010-03-05.orig/drivers/xen/blkback/vbd.c	2009-06-09 15:50:31.000000000 +0200
+++ sle11sp1-2010-03-05/drivers/xen/blkback/vbd.c	2010-03-08 10:33:07.000000000 +0100
@@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
 	}
 
 	vbd->bdev = bdev;
+	vbd->size = vbd_size(vbd);
 
 	if (vbd->bdev->bd_disk == NULL) {
 		DPRINTK("vbd_creat: device %08x doesn't exist.\n",
@@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req, 
  out:
 	return rc;
 }
+
+void vbd_resize(blkif_t *blkif)
+{
+	struct vbd *vbd = &blkif->vbd;
+	struct xenbus_transaction xbt;
+	int err;
+	struct xenbus_device *dev = blkif->be->dev;
+	unsigned long long new_size = vbd_size(vbd);
+
+	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
+	vbd->size = new_size;
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		printk(KERN_WARNING "Error starting transaction");
+		return;
+	}
+	err = xenbus_printf(xbt, dev->nodename, "sectors", "%Lu",
+			    vbd_size(vbd));
+	if (err) {
+		printk(KERN_WARNING "Error writing new size");
+		goto abort;
+	}
+	/*
+	 * Write the current state; we will use this to synchronize
+	 * the front-end. If the current state is "connected" the
+	 * front-end will get the new size information online.
+	 */
+	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
+	if (err) {
+		printk(KERN_WARNING "Error writing the state");
+		goto abort;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err == -EAGAIN)
+		goto again;
+	if (err)
+		printk(KERN_WARNING "Error ending transaction");
+abort:
+	xenbus_transaction_end(xbt, 1);
+}
--- sle11sp1-2010-03-05.orig/drivers/xen/blkback/common.h	2010-01-04 13:22:59.000000000 +0100
+++ sle11sp1-2010-03-05/drivers/xen/blkback/common.h	2010-03-08 10:32:11.000000000 +0100
@@ -56,6 +56,7 @@ struct vbd {
 	unsigned char  type;        /* VDISK_xxx */
 	u32            pdevice;     /* phys device that this vbd maps to */
 	struct block_device *bdev;
+	sector_t       size;        /* Cached size parameter */
 };
 
 struct backend_info;
@@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
 void blkif_disconnect(blkif_t *blkif);
 void blkif_free(blkif_t *blkif);
 int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int evtchn);
+void vbd_resize(blkif_t *blkif);
 
 #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
 #define blkif_put(_b)					\
--- sle11sp1-2010-03-05.orig/drivers/xen/blkfront/blkfront.c	2010-03-01 14:45:47.000000000 +0100
+++ sle11sp1-2010-03-05/drivers/xen/blkfront/blkfront.c	2010-03-08 10:36:03.000000000 +0100
@@ -330,9 +330,24 @@ static void connect(struct blkfront_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;
+	}
 
 	DPRINTK("blkfront.c:connect:%s.\n", info->xbdev->otherend);
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 19:56 [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
@ 2010-03-09 20:15 ` Pasi Kärkkäinen
  2010-03-09 20:31   ` Ky Srinivasan
  2010-03-12 10:41 ` J. Roeleveld
  2010-03-15  9:26 ` Jan Beulich
  2 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-09 20:15 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: xen-devel

On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
> The attached patch supports dynamic resizing of vbds.
> 

Nice! Did you also implement the xm/xend side of resizing? 

I implemented xm/xend support for online resizing a couple of months ago, 
but I was not done with the blkback/blkfront code yet.. well, no need for that now :)

-- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 20:15 ` Pasi Kärkkäinen
@ 2010-03-09 20:31   ` Ky Srinivasan
  2010-03-09 20:35     ` Pasi Kärkkäinen
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-09 20:31 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: xen-devel



>>> On 3/9/2010 at  3:15 PM, in message <20100309201529.GH1878@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>> The attached patch supports dynamic resizing of vbds.
>> 
> 
> Nice! Did you also implement the xm/xend side of resizing? 
My goal was to not have the end-user do anything other than what was minimally required to  resizing the device on the host side. Once the device is resized on the host side, this capacity change is propagated to the guest without having to invoke any xm command.

Regards,

K. Y
> 
> I implemented xm/xend support for online resizing a couple of months ago, 
> but I was not done with the blkback/blkfront code yet.. well, no need for 
> that now :)
> 
> -- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 20:31   ` Ky Srinivasan
@ 2010-03-09 20:35     ` Pasi Kärkkäinen
  2010-03-09 20:39       ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-09 20:35 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: xen-devel

On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
> 
> 
> >>> On 3/9/2010 at  3:15 PM, in message <20100309201529.GH1878@reaktio.net>, Pasi
> Kärkkäinen<pasik@iki.fi> wrote: 
> > On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
> >> The attached patch supports dynamic resizing of vbds.
> >> 
> > 
> > Nice! Did you also implement the xm/xend side of resizing? 
> My goal was to not have the end-user do anything other than what 
> was minimally required to  resizing the device on the host side. 
> Once the device is resized on the host side, this capacity change 
> is propagated to the guest without having to invoke any xm command.
> 

Oh, even better!
What version of the kernel did you test with? 2.6.27? 

-- Pasi

> Regards,
> 
> K. Y
> > 
> > I implemented xm/xend support for online resizing a couple of months ago, 
> > but I was not done with the blkback/blkfront code yet.. well, no need for 
> > that now :)
> > 
> > -- Pasi
> 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 20:35     ` Pasi Kärkkäinen
@ 2010-03-09 20:39       ` Ky Srinivasan
  2010-03-11 20:15         ` Pasi Kärkkäinen
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-09 20:39 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: xen-devel



>>> On 3/9/2010 at  3:35 PM, in message <20100309203557.GJ1878@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>> 
>> 
>> >>> On 3/9/2010 at  3:15 PM, in message <20100309201529.GH1878@reaktio.net>, Pasi
>> Kärkkäinen<pasik@iki.fi> wrote: 
>> > On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>> >> The attached patch supports dynamic resizing of vbds.
>> >> 
>> > 
>> > Nice! Did you also implement the xm/xend side of resizing? 
>> My goal was to not have the end-user do anything other than what 
>> was minimally required to  resizing the device on the host side. 
>> Once the device is resized on the host side, this capacity change 
>> is propagated to the guest without having to invoke any xm command.
>> 
> 
> Oh, even better!
> What version of the kernel did you test with? 2.6.27? 
I tested this on 2.6.32. The patches should apply to earlier kernels without too much trouble.

Regards,

K. Y
> 
> -- Pasi
> 
>> Regards,
>> 
>> K. Y
>> > 
>> > I implemented xm/xend support for online resizing a couple of months ago, 
>> > but I was not done with the blkback/blkfront code yet.. well, no need for 
>> > that now :)
>> > 
>> > -- Pasi
>> 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 20:39       ` Ky Srinivasan
@ 2010-03-11 20:15         ` Pasi Kärkkäinen
  2010-03-11 21:44           ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-11 20:15 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: Jeremy Fitzhardinge, xen-devel, James Harper

On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
> 
> 
> >>> On 3/9/2010 at  3:35 PM, in message <20100309203557.GJ1878@reaktio.net>, Pasi
> Kärkkäinen<pasik@iki.fi> wrote: 
> > On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
> >> 
> >> 
> >> >>> On 3/9/2010 at  3:15 PM, in message <20100309201529.GH1878@reaktio.net>, Pasi
> >> Kärkkäinen<pasik@iki.fi> wrote: 
> >> > On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
> >> >> The attached patch supports dynamic resizing of vbds.
> >> >> 
> >> > 
> >> > Nice! Did you also implement the xm/xend side of resizing? 
> >> My goal was to not have the end-user do anything other than what 
> >> was minimally required to  resizing the device on the host side. 
> >> Once the device is resized on the host side, this capacity change 
> >> is propagated to the guest without having to invoke any xm command.
> >> 
> > 
> > Oh, even better!
> > What version of the kernel did you test with? 2.6.27? 
> I tested this on 2.6.32. The patches should apply to earlier kernels without too much trouble.
> 

Great!

Jeremy: Hopefully you can add this patch to your tree.

James: Would be nice to have similar online-resizing support also in gplpv frontends!

-- Pasi


> Regards,
> 
> K. Y
> > 
> > -- Pasi
> > 
> >> Regards,
> >> 
> >> K. Y
> >> > 
> >> > I implemented xm/xend support for online resizing a couple of months ago, 
> >> > but I was not done with the blkback/blkfront code yet.. well, no need for 
> >> > that now :)
> >> > 
> >> > -- Pasi
> >> 
> 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-11 20:15         ` Pasi Kärkkäinen
@ 2010-03-11 21:44           ` Jeremy Fitzhardinge
  2010-03-11 22:01             ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Jeremy Fitzhardinge @ 2010-03-11 21:44 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ky Srinivasan, xen-devel, James Harper

On 03/11/2010 12:15 PM, Pasi Kärkkäinen wrote:
> On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
>    
>>
>>      
>>>>> On 3/9/2010 at  3:35 PM, in message<20100309203557.GJ1878@reaktio.net>, Pasi
>>>>>            
>> Kärkkäinen<pasik@iki.fi>  wrote:
>>      
>>> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>>>        
>>>>
>>>>          
>>>>>>> On 3/9/2010 at  3:15 PM, in message<20100309201529.GH1878@reaktio.net>, Pasi
>>>>>>>                
>>>> Kärkkäinen<pasik@iki.fi>  wrote:
>>>>          
>>>>> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>>>>>            
>>>>>> The attached patch supports dynamic resizing of vbds.
>>>>>>
>>>>>>              
>>>>> Nice! Did you also implement the xm/xend side of resizing?
>>>>>            
>>>> My goal was to not have the end-user do anything other than what
>>>> was minimally required to  resizing the device on the host side.
>>>> Once the device is resized on the host side, this capacity change
>>>> is propagated to the guest without having to invoke any xm command.
>>>>
>>>>          
>>> Oh, even better!
>>> What version of the kernel did you test with? 2.6.27?
>>>        
>> I tested this on 2.6.32. The patches should apply to earlier kernels without too much trouble.
>>
>>      
> Great!
>
> Jeremy: Hopefully you can add this patch to your tree.
>    

It applied fairly cleanly, but I haven't tested it yet.  Ky, by 2.6.32 I 
assume I mean your one, not pvops? (Because your patch is touching 
blkfront in the wrong place.)

     J

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-11 21:44           ` Jeremy Fitzhardinge
@ 2010-03-11 22:01             ` Ky Srinivasan
  2010-03-11 23:13               ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-11 22:01 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, pasik; +Cc: James Harper, xen-devel



>>> On 3/11/2010 at  4:44 PM, in message <4B996436.1000600@goop.org>, Jeremy
Fitzhardinge <jeremy@goop.org> wrote: 
> On 03/11/2010 12:15 PM, Pasi Kärkkäinen wrote:
>> On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
>>    
>>>
>>>      
>>>>>> On 3/9/2010 at  3:35 PM, in message<20100309203557.GJ1878@reaktio.net>, Pasi
>>>>>>            
>>> Kärkkäinen<pasik@iki.fi>  wrote:
>>>      
>>>> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>>>>        
>>>>>
>>>>>          
>>>>>>>> On 3/9/2010 at  3:15 PM, in message<20100309201529.GH1878@reaktio.net>, Pasi
>>>>>>>>                
>>>>> Kärkkäinen<pasik@iki.fi>  wrote:
>>>>>          
>>>>>> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>>>>>>            
>>>>>>> The attached patch supports dynamic resizing of vbds.
>>>>>>>
>>>>>>>              
>>>>>> Nice! Did you also implement the xm/xend side of resizing?
>>>>>>            
>>>>> My goal was to not have the end-user do anything other than what
>>>>> was minimally required to  resizing the device on the host side.
>>>>> Once the device is resized on the host side, this capacity change
>>>>> is propagated to the guest without having to invoke any xm command.
>>>>>
>>>>>          
>>>> Oh, even better!
>>>> What version of the kernel did you test with? 2.6.27?
>>>>        
>>> I tested this on 2.6.32. The patches should apply to earlier kernels without 
> too much trouble.
>>>
>>>      
>> Great!
>>
>> Jeremy: Hopefully you can add this patch to your tree.
>>    
> 
> It applied fairly cleanly, but I haven't tested it yet.  Ky, by 2.6.32 I 
> assume I mean your one, not pvops? (Because your patch is touching 
> blkfront in the wrong place.)

Yes. This patch was against our sles11 sp1.

Regards,

K. Y
> 
>      J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-11 22:01             ` Ky Srinivasan
@ 2010-03-11 23:13               ` Jeremy Fitzhardinge
  2010-03-12  2:52                 ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Jeremy Fitzhardinge @ 2010-03-11 23:13 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: James Harper, xen-devel

On 03/11/2010 02:01 PM, Ky Srinivasan wrote:
>
>    
>>>> On 3/11/2010 at  4:44 PM, in message<4B996436.1000600@goop.org>, Jeremy
>>>>          
> Fitzhardinge<jeremy@goop.org>  wrote:
>    
>> On 03/11/2010 12:15 PM, Pasi Kärkkäinen wrote:
>>      
>>> On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
>>>
>>>        
>>>>
>>>>          
>>>>>>> On 3/9/2010 at  3:35 PM, in message<20100309203557.GJ1878@reaktio.net>, Pasi
>>>>>>>
>>>>>>>                
>>>> Kärkkäinen<pasik@iki.fi>   wrote:
>>>>
>>>>          
>>>>> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>>>>>
>>>>>            
>>>>>>
>>>>>>              
>>>>>>>>> On 3/9/2010 at  3:15 PM, in message<20100309201529.GH1878@reaktio.net>, Pasi
>>>>>>>>>
>>>>>>>>>                    
>>>>>> Kärkkäinen<pasik@iki.fi>   wrote:
>>>>>>
>>>>>>              
>>>>>>> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> The attached patch supports dynamic resizing of vbds.
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> Nice! Did you also implement the xm/xend side of resizing?
>>>>>>>
>>>>>>>                
>>>>>> My goal was to not have the end-user do anything other than what
>>>>>> was minimally required to  resizing the device on the host side.
>>>>>> Once the device is resized on the host side, this capacity change
>>>>>> is propagated to the guest without having to invoke any xm command.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Oh, even better!
>>>>> What version of the kernel did you test with? 2.6.27?
>>>>>
>>>>>            
>>>> I tested this on 2.6.32. The patches should apply to earlier kernels without
>>>>          
>> too much trouble.
>>      
>>>>
>>>>          
>>> Great!
>>>
>>> Jeremy: Hopefully you can add this patch to your tree.
>>>
>>>        
>> It applied fairly cleanly, but I haven't tested it yet.  Ky, by 2.6.32 I
>> assume I mean your one, not pvops? (Because your patch is touching
>> blkfront in the wrong place.)
>>      
> Yes. This patch was against our sles11 sp1.
>    

What happens if the frontend doesn't support the resize, and the device 
shrinks?  Will the backend just raise IO errors for out of range requests?

     J

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-11 23:13               ` Jeremy Fitzhardinge
@ 2010-03-12  2:52                 ` Ky Srinivasan
  0 siblings, 0 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-12  2:52 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: James Harper, xen-devel



>>> On 3/11/2010 at  6:13 PM, in message <4B997922.1080407@goop.org>, Jeremy
Fitzhardinge <jeremy@goop.org> wrote: 
> On 03/11/2010 02:01 PM, Ky Srinivasan wrote:
>>
>>    
>>>>> On 3/11/2010 at  4:44 PM, in message<4B996436.1000600@goop.org>, Jeremy
>>>>>          
>> Fitzhardinge<jeremy@goop.org>  wrote:
>>    
>>> On 03/11/2010 12:15 PM, Pasi Kärkkäinen wrote:
>>>      
>>>> On Tue, Mar 09, 2010 at 01:39:23PM -0700, Ky Srinivasan wrote:
>>>>
>>>>        
>>>>>
>>>>>          
>>>>>>>> On 3/9/2010 at  3:35 PM, in message<20100309203557.GJ1878@reaktio.net>, Pasi
>>>>>>>>
>>>>>>>>                
>>>>> Kärkkäinen<pasik@iki.fi>   wrote:
>>>>>
>>>>>          
>>>>>> On Tue, Mar 09, 2010 at 01:31:17PM -0700, Ky Srinivasan wrote:
>>>>>>
>>>>>>            
>>>>>>>
>>>>>>>              
>>>>>>>>>> On 3/9/2010 at  3:15 PM, in message<20100309201529.GH1878@reaktio.net>, Pasi
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>> Kärkkäinen<pasik@iki.fi>   wrote:
>>>>>>>
>>>>>>>              
>>>>>>>> On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan wrote:
>>>>>>>>
>>>>>>>>                
>>>>>>>>> The attached patch supports dynamic resizing of vbds.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>> Nice! Did you also implement the xm/xend side of resizing?
>>>>>>>>
>>>>>>>>                
>>>>>>> My goal was to not have the end-user do anything other than what
>>>>>>> was minimally required to  resizing the device on the host side.
>>>>>>> Once the device is resized on the host side, this capacity change
>>>>>>> is propagated to the guest without having to invoke any xm command.
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> Oh, even better!
>>>>>> What version of the kernel did you test with? 2.6.27?
>>>>>>
>>>>>>            
>>>>> I tested this on 2.6.32. The patches should apply to earlier kernels without
>>>>>          
>>> too much trouble.
>>>      
>>>>>
>>>>>          
>>>> Great!
>>>>
>>>> Jeremy: Hopefully you can add this patch to your tree.
>>>>
>>>>        
>>> It applied fairly cleanly, but I haven't tested it yet.  Ky, by 2.6.32 I
>>> assume I mean your one, not pvops? (Because your patch is touching
>>> blkfront in the wrong place.)
>>>      
>> Yes. This patch was against our sles11 sp1.
>>    
> 
> What happens if the frontend doesn't support the resize, and the device 
> shrinks?  Will the backend just raise IO errors for out of range requests?

Clearly, resizing is an operation that ought to be done with great care and co-ordination between the administrators of the guest and the host. If the device on the host side is shrunk without co-ordinating with the guest,  seeing I/O errors will be the least of our problems!  
The situation you describe can occur today without this patch - consider the case where an LVM based device is resized on the host side (device is shrunk as in your example). We will be generating I/O errors for out of range request on the backend in this scenario. Assuming all the co-ordination is done, this patch automates propagating the capacity change without having to detach and attach the storage from the guest.

Regards,

K. Y 
> 
>      J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 19:56 [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
  2010-03-09 20:15 ` Pasi Kärkkäinen
@ 2010-03-12 10:41 ` J. Roeleveld
  2010-03-14 13:49   ` Andrew Lyon
  2010-03-15  9:26 ` Jan Beulich
  2 siblings, 1 reply; 32+ messages in thread
From: J. Roeleveld @ 2010-03-12 10:41 UTC (permalink / raw)
  To: xen-devel

On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
> The attached patch supports dynamic resizing of vbds.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> 

Thank you for this.

The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)

I will test the patch on my system during the next week and provide feedback.

--
Joost Roeleveld

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-12 10:41 ` J. Roeleveld
@ 2010-03-14 13:49   ` Andrew Lyon
  2010-03-14 14:06     ` Pasi Kärkkäinen
                       ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Andrew Lyon @ 2010-03-14 13:49 UTC (permalink / raw)
  To: J. Roeleveld; +Cc: ksrinivasan, xen-devel

On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> The attached patch supports dynamic resizing of vbds.
>>
>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>>
>
> Thank you for this.
>
> The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
>
> I will test the patch on my system during the next week and provide feedback.
>
> --
> Joost Roeleveld
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:

dom0: VBD Resize: new size 172032
domU: Setting capacity to 172032

I extended the filesystem and filled up the available space, then
extended again:

dom0: VBD Resize: new size 376832
domU: Setting capacity to 376832

fsck, badblocks, and testing a tarball I had filled the filesystem
with revealed no problems, so I decided to try reducing the
filesystem, first using resize2fs, then reducing the size of the block
device, although some errors were logged in domU the operation seemed
to work ok:

dom0: VBD Resize: new size 114688
domU: Setting capacity to 114688
domU: end_request: I/O error, dev sdb1, sector 212984
domU: Buffer I/O error on device sdb1, logical block 26623

I did notice that it seemed to be necessary to "poke" the device using
cfdisk /dev/sdb1 before domU would notice the new size, but on the
whole everything works nicely and this is a very useful new feature!

Andy

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-14 13:49   ` Andrew Lyon
@ 2010-03-14 14:06     ` Pasi Kärkkäinen
  2010-03-16  3:04       ` Ky Srinivasan
  2010-03-16  3:05       ` Ky Srinivasan
  2010-03-16  2:50     ` [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
  2010-03-16  3:03     ` Ky Srinivasan
  2 siblings, 2 replies; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-14 14:06 UTC (permalink / raw)
  To: Andrew Lyon; +Cc: ksrinivasan, J. Roeleveld, xen-devel

On Sun, Mar 14, 2010 at 01:49:38PM +0000, Andrew Lyon wrote:
> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
> > On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
> >> The attached patch supports dynamic resizing of vbds.
> >>
> >> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> >>
> >
> > Thank you for this.
> >
> > The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
> >
> > I will test the patch on my system during the next week and provide feedback.
> >
> > --
> > Joost Roeleveld
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> 
> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
> 
> dom0: VBD Resize: new size 172032
> domU: Setting capacity to 172032
>

Btw it would be good to add the vbd-device and domU name to these log entries in the dom0,
and the device name in domU!
 
> I extended the filesystem and filled up the available space, then
> extended again:
> 
> dom0: VBD Resize: new size 376832
> domU: Setting capacity to 376832
> 
> fsck, badblocks, and testing a tarball I had filled the filesystem
> with revealed no problems, so I decided to try reducing the
> filesystem, first using resize2fs, then reducing the size of the block
> device, although some errors were logged in domU the operation seemed
> to work ok:
> 
> dom0: VBD Resize: new size 114688
> domU: Setting capacity to 114688
> domU: end_request: I/O error, dev sdb1, sector 212984
> domU: Buffer I/O error on device sdb1, logical block 26623
> 
> I did notice that it seemed to be necessary to "poke" the device using
> cfdisk /dev/sdb1 before domU would notice the new size, but on the
> whole everything works nicely and this is a very useful new feature!
> 

Good to hear it works!

-- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-09 19:56 [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
  2010-03-09 20:15 ` Pasi Kärkkäinen
  2010-03-12 10:41 ` J. Roeleveld
@ 2010-03-15  9:26 ` Jan Beulich
  2 siblings, 0 replies; 32+ messages in thread
From: Jan Beulich @ 2010-03-15  9:26 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Ky Srinivasan, xen-devel

Keir,

is there a particular reason you did not apply this to the 2.6.18 tree so far?

Thanks, Jan

>>> "Ky Srinivasan" <ksrinivasan@novell.com> 09.03.10 20:56 >>>
The attached patch supports dynamic resizing of vbds.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-14 13:49   ` Andrew Lyon
  2010-03-14 14:06     ` Pasi Kärkkäinen
@ 2010-03-16  2:50     ` Ky Srinivasan
  2010-03-16 21:24       ` J. Roeleveld
  2010-03-16  3:03     ` Ky Srinivasan
  2 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-16  2:50 UTC (permalink / raw)
  To: J. Roeleveld, Andrew Lyon; +Cc: xen-devel



>>> On 3/14/2010 at  9:49 AM, in message
<f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
<andrew.lyon@gmail.com> wrote: 
> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
>> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>>> The attached patch supports dynamic resizing of vbds.
>>>
>>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>>>
>>
>> Thank you for this.
>>
>> The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
>>
>> I will test the patch on my system during the next week and provide 
> feedback.
Thanks. Looking forward to your feedback.

K. Y
>>
>> --
>> Joost Roeleveld
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> 
> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
> 
> dom0: VBD Resize: new size 172032
> domU: Setting capacity to 172032
> 
> I extended the filesystem and filled up the available space, then
> extended again:
> 
> dom0: VBD Resize: new size 376832
> domU: Setting capacity to 376832
> 
> fsck, badblocks, and testing a tarball I had filled the filesystem
> with revealed no problems, so I decided to try reducing the
> filesystem, first using resize2fs, then reducing the size of the block
> device, although some errors were logged in domU the operation seemed
> to work ok:
> 
> dom0: VBD Resize: new size 114688
> domU: Setting capacity to 114688
> domU: end_request: I/O error, dev sdb1, sector 212984
> domU: Buffer I/O error on device sdb1, logical block 26623
> 
> I did notice that it seemed to be necessary to "poke" the device using
> cfdisk /dev/sdb1 before domU would notice the new size, but on the
> whole everything works nicely and this is a very useful new feature!
> 
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-14 13:49   ` Andrew Lyon
  2010-03-14 14:06     ` Pasi Kärkkäinen
  2010-03-16  2:50     ` [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
@ 2010-03-16  3:03     ` Ky Srinivasan
  2 siblings, 0 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-16  3:03 UTC (permalink / raw)
  To: J. Roeleveld, Andrew Lyon; +Cc: xen-devel



>>> On 3/14/2010 at  9:49 AM, in message
<f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
<andrew.lyon@gmail.com> wrote: 
> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
>> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>>> The attached patch supports dynamic resizing of vbds.
>>>
>>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>>>
>>
>> Thank you for this.
>>
>> The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
>>
>> I will test the patch on my system during the next week and provide 
> feedback.
>>
>> --
>> Joost Roeleveld
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> 
> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
Thanks for the testing.

K. Y
> 
> dom0: VBD Resize: new size 172032
> domU: Setting capacity to 172032
> 
> I extended the filesystem and filled up the available space, then
> extended again:
> 
> dom0: VBD Resize: new size 376832
> domU: Setting capacity to 376832
> 
> fsck, badblocks, and testing a tarball I had filled the filesystem
> with revealed no problems, so I decided to try reducing the
> filesystem, first using resize2fs, then reducing the size of the block
> device, although some errors were logged in domU the operation seemed
> to work ok:
> 
> dom0: VBD Resize: new size 114688
> domU: Setting capacity to 114688
> domU: end_request: I/O error, dev sdb1, sector 212984
> domU: Buffer I/O error on device sdb1, logical block 26623
> 
> I did notice that it seemed to be necessary to "poke" the device using
> cfdisk /dev/sdb1 before domU would notice the new size, but on the
> whole everything works nicely and this is a very useful new feature!
The capacity change is noticed on the back-end only when there is some activity on the device as this is done in the context of the dedicated thread.

K. Y
> 
> Andy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-14 14:06     ` Pasi Kärkkäinen
@ 2010-03-16  3:04       ` Ky Srinivasan
  2010-03-16  3:05       ` Ky Srinivasan
  1 sibling, 0 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-16  3:04 UTC (permalink / raw)
  To: Andrew Lyon, Pasi Kärkkäinen; +Cc: J. Roeleveld, xen-devel



>>> On 3/14/2010 at 10:06 AM, in message <20100314140647.GJ1878@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Sun, Mar 14, 2010 at 01:49:38PM +0000, Andrew Lyon wrote:
>> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
>> > On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> >> The attached patch supports dynamic resizing of vbds.
>> >>
>> >> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>> >>
>> >
>> > Thank you for this.
>> >
>> > The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
>> >
>> > I will test the patch on my system during the next week and provide 
> feedback.
>> >
>> > --
>> > Joost Roeleveld
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>> >
>> 
>> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
>> 
>> dom0: VBD Resize: new size 172032
>> domU: Setting capacity to 172032
>>
> 
> Btw it would be good to add the vbd-device and domU name to these log entries 
> in the dom0,
> and the device name in domU!

Agreed. Will send out the patch soon.

K. Y
>  
>> I extended the filesystem and filled up the available space, then
>> extended again:
>> 
>> dom0: VBD Resize: new size 376832
>> domU: Setting capacity to 376832
>> 
>> fsck, badblocks, and testing a tarball I had filled the filesystem
>> with revealed no problems, so I decided to try reducing the
>> filesystem, first using resize2fs, then reducing the size of the block
>> device, although some errors were logged in domU the operation seemed
>> to work ok:
>> 
>> dom0: VBD Resize: new size 114688
>> domU: Setting capacity to 114688
>> domU: end_request: I/O error, dev sdb1, sector 212984
>> domU: Buffer I/O error on device sdb1, logical block 26623
>> 
>> I did notice that it seemed to be necessary to "poke" the device using
>> cfdisk /dev/sdb1 before domU would notice the new size, but on the
>> whole everything works nicely and this is a very useful new feature!
>> 
> 
> Good to hear it works!
> 
> -- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-14 14:06     ` Pasi Kärkkäinen
  2010-03-16  3:04       ` Ky Srinivasan
@ 2010-03-16  3:05       ` Ky Srinivasan
  2010-07-20 18:27         ` Pasi Kärkkäinen
  1 sibling, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-16  3:05 UTC (permalink / raw)
  To: Andrew Lyon, Pasi Kärkkäinen; +Cc: J. Roeleveld, xen-devel



>>> On 3/14/2010 at 10:06 AM, in message <20100314140647.GJ1878@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Sun, Mar 14, 2010 at 01:49:38PM +0000, Andrew Lyon wrote:
>> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
>> > On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> >> The attached patch supports dynamic resizing of vbds.
>> >>
>> >> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>> >>
>> >
>> > Thank you for this.
>> >
>> > The patch applied succesfully against the gentoo-xen kernel (2.6.29-xen-r4)
>> >
>> > I will test the patch on my system during the next week and provide 
> feedback.
>> >
>> > --
>> > Joost Roeleveld
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>> >
>> 
>> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
>> 
>> dom0: VBD Resize: new size 172032
>> domU: Setting capacity to 172032
>>
> 
> Btw it would be good to add the vbd-device and domU name to these log entries 
> in the dom0,
> and the device name in domU!

Agreed. Will send out the patch soon.

K. Y
>  
>> I extended the filesystem and filled up the available space, then
>> extended again:
>> 
>> dom0: VBD Resize: new size 376832
>> domU: Setting capacity to 376832
>> 
>> fsck, badblocks, and testing a tarball I had filled the filesystem
>> with revealed no problems, so I decided to try reducing the
>> filesystem, first using resize2fs, then reducing the size of the block
>> device, although some errors were logged in domU the operation seemed
>> to work ok:
>> 
>> dom0: VBD Resize: new size 114688
>> domU: Setting capacity to 114688
>> domU: end_request: I/O error, dev sdb1, sector 212984
>> domU: Buffer I/O error on device sdb1, logical block 26623
>> 
>> I did notice that it seemed to be necessary to "poke" the device using
>> cfdisk /dev/sdb1 before domU would notice the new size, but on the
>> whole everything works nicely and this is a very useful new feature!
>> 
> 
> Good to hear it works!
> 
> -- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16  2:50     ` [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
@ 2010-03-16 21:24       ` J. Roeleveld
  2010-03-16 21:27         ` J. Roeleveld
  2010-03-17 15:09         ` Ky Srinivasan
  0 siblings, 2 replies; 32+ messages in thread
From: J. Roeleveld @ 2010-03-16 21:24 UTC (permalink / raw)
  To: xen-devel

On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:
> >>> On 3/14/2010 at  9:49 AM, in message
> 
> <f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
> 
> <andrew.lyon@gmail.com> wrote:
> > On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
> >> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
> >>> The attached patch supports dynamic resizing of vbds.
> >>>
> >>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> >>
> >> Thank you for this.
> >>
> >> The patch applied succesfully against the gentoo-xen kernel
> >> (2.6.29-xen-r4)
> >>
> >> I will test the patch on my system during the next week and provide
> >
> > feedback.
> 
> Thanks. Looking forward to your feedback.
> 
> K. Y

Ok, finally got time to test it.
Not seen any major crashes, but my domU and filesystem did end up in an 
unusable state.

I also noticed that the change-entries in the logs didn't show up until I 
"touched" the drive.
Eg: "ls <mount point>"

When trying to do an online resize, "resize2fs" refused, saying the filesystem 
was already using the full space:
--
storage ~ # resize2fs /dev/sdb1   
resize2fs 1.41.9 (22-Aug-2009)    
The filesystem is already 104857600 blocks long.  Nothing to do!
--

This was then 'resolved' by umount/mount of the filesystem:
--
storage ~ # umount /data/homes/                                                                                                                                                                                                             
storage ~ # mount /data/homes/                                                                                                                                                                                                             
storage ~ # resize2fs /dev/sdb1 
resize2fs 1.41.9 (22-Aug-2009)  
Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing required
old desc_blocks = 25, new_desc_blocks = 29                                  
Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.         
--

These actions were take in the domU.

The patch informs the domU about the new size, but the new size is not 
cascaded to all the levels.

I'm not familiar enough with the kernel internals to point to where the 
missing part is.

My ideal situation would allow the folliowing to work without additional 
steps:

dom0: lvresize -L+10G /dev/vg/foo
domU: resizefs /dev/sdb1

(with "/dev/vg/foo" exported to domU as "/dev/sdb1")

Right now, I need to do the following:
dom0: lvresize -L+10G /dev/vg/foo
domU: ls /mnt/sdb1
domU: umount /mnt/sdb1
domU: mount /mnt/sdb1
domU: resizefs /dev/sdb1

During the 2nd attempt, when trying to umount the filesystem after increasing 
it again leads to the domU having a 100% I/O wait.
The logs themselves do not, however, show any usefull information.

I waited for about 30 minutes and saw no change to this situation.

I am afraid that for now I will revert back to not having this patch applied 
and use the 'current' method of increasing the filesystem sizes.

Please let me know if there is any further testing I can help with.

--
Joost Roeleveld

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16 21:24       ` J. Roeleveld
@ 2010-03-16 21:27         ` J. Roeleveld
  2010-03-16 22:04           ` J. Roeleveld
  2010-03-17 15:33           ` Ky Srinivasan
  2010-03-17 15:09         ` Ky Srinivasan
  1 sibling, 2 replies; 32+ messages in thread
From: J. Roeleveld @ 2010-03-16 21:27 UTC (permalink / raw)
  To: xen-devel

On Tuesday 16 March 2010 22:24:02 J. Roeleveld wrote:
> On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:
> > >>> On 3/14/2010 at  9:49 AM, in message
> >
> > <f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
> >
> > <andrew.lyon@gmail.com> wrote:
> > > On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> 
wrote:
> > >> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
> > >>> The attached patch supports dynamic resizing of vbds.
> > >>>
> > >>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> > >>
> > >> Thank you for this.
> > >>
> > >> The patch applied succesfully against the gentoo-xen kernel
> > >> (2.6.29-xen-r4)
> > >>
> > >> I will test the patch on my system during the next week and provide
> > >
> > > feedback.
> >
> > Thanks. Looking forward to your feedback.
> >
> > K. Y
> 
> Ok, finally got time to test it.
> Not seen any major crashes, but my domU and filesystem did end up in an
> unusable state.
> 
> I also noticed that the change-entries in the logs didn't show up until I
> "touched" the drive.
> Eg: "ls <mount point>"
> 
> When trying to do an online resize, "resize2fs" refused, saying the
>  filesystem was already using the full space:
> --
> storage ~ # resize2fs /dev/sdb1
> resize2fs 1.41.9 (22-Aug-2009)
> The filesystem is already 104857600 blocks long.  Nothing to do!
> --
> 
> This was then 'resolved' by umount/mount of the filesystem:
> --
> storage ~ # umount /data/homes/
> storage ~ # mount /data/homes/
> storage ~ # resize2fs /dev/sdb1
> resize2fs 1.41.9 (22-Aug-2009)
> Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing
>  required old desc_blocks = 25, new_desc_blocks = 29
> Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.
> --
> 
> These actions were take in the domU.
> 
> The patch informs the domU about the new size, but the new size is not
> cascaded to all the levels.
> 
> I'm not familiar enough with the kernel internals to point to where the
> missing part is.
> 
> My ideal situation would allow the folliowing to work without additional
> steps:
> 
> dom0: lvresize -L+10G /dev/vg/foo
> domU: resizefs /dev/sdb1
> 
> (with "/dev/vg/foo" exported to domU as "/dev/sdb1")
> 
> Right now, I need to do the following:
> dom0: lvresize -L+10G /dev/vg/foo
> domU: ls /mnt/sdb1
> domU: umount /mnt/sdb1
> domU: mount /mnt/sdb1
> domU: resizefs /dev/sdb1
> 
> During the 2nd attempt, when trying to umount the filesystem after
>  increasing it again leads to the domU having a 100% I/O wait.
> The logs themselves do not, however, show any usefull information.
> 
> I waited for about 30 minutes and saw no change to this situation.
> 
> I am afraid that for now I will revert back to not having this patch
>  applied and use the 'current' method of increasing the filesystem sizes.
> 
> Please let me know if there is any further testing I can help with.
> 
> --
> Joost Roeleveld
> 

Update,

After killing the domU, I saw the following in my dom0:

--
VBD Resize: new size 943718400
VBD Resize: new size 1048576000
INFO: task blkback.3.sdb1:21647 blocked for more than 480 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
blkback.3.sdb D 0000000000000002     0 21647      2
 ffff88002b54f550 0000000000000246 ffff88002ef08000 0000000600000000
 ffff88002f9bf800 ffffffff806952c0 ffffffff806952c0 ffff88002eeee550
 ffff88002b54f778 000000002eee6800 0000000000000000 ffff88002b54f778
Call Trace:
 [<ffffffff804d6ece>] printk+0x4e/0x58
 [<ffffffff804d9387>] __down_read+0x101/0x119
 [<ffffffff803d301e>] xenbus_transaction_start+0x15/0x62
 [<ffffffff803d8843>] vbd_resize+0x50/0x120
 [<ffffffff803d747c>] blkif_schedule+0x7e/0x4ae
 [<ffffffff803d73fe>] blkif_schedule+0x0/0x4ae
 [<ffffffff8023f8de>] kthread+0x47/0x73
 [<ffffffff8020b2ea>] child_rip+0xa/0x20
 [<ffffffff8023f897>] kthread+0x0/0x73
 [<ffffffff8020b2e0>] child_rip+0x0/0x20
--

(this was the result from "dmesg"

The ID of the domU was "3" and the device of the filesystem in the domU is 
"sdb1"
Eg. this matches the above error-message.

--
Joost

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16 21:27         ` J. Roeleveld
@ 2010-03-16 22:04           ` J. Roeleveld
  2010-03-17 15:33           ` Ky Srinivasan
  1 sibling, 0 replies; 32+ messages in thread
From: J. Roeleveld @ 2010-03-16 22:04 UTC (permalink / raw)
  To: xen-devel

On Tuesday 16 March 2010 22:27:12 J. Roeleveld wrote:
> On Tuesday 16 March 2010 22:24:02 J. Roeleveld wrote:
> > On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:

> > > Thanks. Looking forward to your feedback.
> > >
> > > K. Y
> >
> > Ok, finally got time to test it.
> > Not seen any major crashes, but my domU and filesystem did end up in an
> > unusable state.
> >
> > I also noticed that the change-entries in the logs didn't show up until I
> > "touched" the drive.
> > Eg: "ls <mount point>"
> >
> > When trying to do an online resize, "resize2fs" refused, saying the
> >  filesystem was already using the full space:
> > --
> > storage ~ # resize2fs /dev/sdb1
> > resize2fs 1.41.9 (22-Aug-2009)
> > The filesystem is already 104857600 blocks long.  Nothing to do!
> > --
> >
> > This was then 'resolved' by umount/mount of the filesystem:
> > --
> > storage ~ # umount /data/homes/
> > storage ~ # mount /data/homes/
> > storage ~ # resize2fs /dev/sdb1
> > resize2fs 1.41.9 (22-Aug-2009)
> > Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing
> >  required old desc_blocks = 25, new_desc_blocks = 29
> > Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.
> > --
> >
> > These actions were take in the domU.
> >
> > The patch informs the domU about the new size, but the new size is not
> > cascaded to all the levels.
> >
> > I'm not familiar enough with the kernel internals to point to where the
> > missing part is.
> >
> > My ideal situation would allow the folliowing to work without additional
> > steps:
> >
> > dom0: lvresize -L+10G /dev/vg/foo
> > domU: resizefs /dev/sdb1
> >
> > (with "/dev/vg/foo" exported to domU as "/dev/sdb1")
> >
> > Right now, I need to do the following:
> > dom0: lvresize -L+10G /dev/vg/foo
> > domU: ls /mnt/sdb1
> > domU: umount /mnt/sdb1
> > domU: mount /mnt/sdb1
> > domU: resizefs /dev/sdb1
> >
> > During the 2nd attempt, when trying to umount the filesystem after
> >  increasing it again leads to the domU having a 100% I/O wait.
> > The logs themselves do not, however, show any usefull information.
> >
> > I waited for about 30 minutes and saw no change to this situation.
> >
> > I am afraid that for now I will revert back to not having this patch
> >  applied and use the 'current' method of increasing the filesystem sizes.
> >
> > Please let me know if there is any further testing I can help with.
> >
> > --
> > Joost Roeleveld
> 
> Update,
> 
> After killing the domU, I saw the following in my dom0:
> 
> --
> VBD Resize: new size 943718400
> VBD Resize: new size 1048576000
> INFO: task blkback.3.sdb1:21647 blocked for more than 480 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> blkback.3.sdb D 0000000000000002     0 21647      2
>  ffff88002b54f550 0000000000000246 ffff88002ef08000 0000000600000000
>  ffff88002f9bf800 ffffffff806952c0 ffffffff806952c0 ffff88002eeee550
>  ffff88002b54f778 000000002eee6800 0000000000000000 ffff88002b54f778
> Call Trace:
>  [<ffffffff804d6ece>] printk+0x4e/0x58
>  [<ffffffff804d9387>] __down_read+0x101/0x119
>  [<ffffffff803d301e>] xenbus_transaction_start+0x15/0x62
>  [<ffffffff803d8843>] vbd_resize+0x50/0x120
>  [<ffffffff803d747c>] blkif_schedule+0x7e/0x4ae
>  [<ffffffff803d73fe>] blkif_schedule+0x0/0x4ae
>  [<ffffffff8023f8de>] kthread+0x47/0x73
>  [<ffffffff8020b2ea>] child_rip+0xa/0x20
>  [<ffffffff8023f897>] kthread+0x0/0x73
>  [<ffffffff8020b2e0>] child_rip+0x0/0x20
> --
> 
> (this was the result from "dmesg"
> 
> The ID of the domU was "3" and the device of the filesystem in the domU is
> "sdb1"
> Eg. this matches the above error-message.
> 
> --
> Joost
> 

Update 2:
Trying to start the domU after killing it failed as the device was still 
listed as "in-use".

I hope all this helps, if you require any specific information, I am happy to 
provide it as long as the information is physically on the server.
Please note, I had to reboot the physical machine to get the domU back up 
again and the LV has been recreated as I no longer trusted the actual file-
system. (rather start 'fresh' before loading data into it then to find out 
there is an issue once it's filled)

--
Joost

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16 21:24       ` J. Roeleveld
  2010-03-16 21:27         ` J. Roeleveld
@ 2010-03-17 15:09         ` Ky Srinivasan
  1 sibling, 0 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-17 15:09 UTC (permalink / raw)
  To: J. Roeleveld, xen-devel



>>> On 3/16/2010 at  5:24 PM, in message <201003162224.02105.joost@antarean.org>,
"J. Roeleveld" <joost@antarean.org> wrote: 
> On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:
>> >>> On 3/14/2010 at  9:49 AM, in message
>> 
>> <f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
>> 
>> <andrew.lyon@gmail.com> wrote:
>> > On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> wrote:
>> >> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> >>> The attached patch supports dynamic resizing of vbds.
>> >>>
>> >>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>> >>
>> >> Thank you for this.
>> >>
>> >> The patch applied succesfully against the gentoo-xen kernel
>> >> (2.6.29-xen-r4)
>> >>
>> >> I will test the patch on my system during the next week and provide
>> >
>> > feedback.
>> 
>> Thanks. Looking forward to your feedback.
>> 
>> K. Y
> 
> Ok, finally got time to test it.
> Not seen any major crashes, but my domU and filesystem did end up in an 
> unusable state.
> 
> I also noticed that the change-entries in the logs didn't show up until I 
> "touched" the drive.
> Eg: "ls <mount point>"

This is by design. The change made to the device on the host will be propagated to the device in the guest in the context of the dedicated thread in the host that services I/O requests for the device under question. If there is any activity on the device the size information (if it has changed) will be propagated to the guest.

> 
> When trying to do an online resize, "resize2fs" refused, saying the 
> filesystem 
> was already using the full space:
> --
> storage ~ # resize2fs /dev/sdb1   
> resize2fs 1.41.9 (22-Aug-2009)    
> The filesystem is already 104857600 blocks long.  Nothing to do!
> --
> 
> This was then 'resolved' by umount/mount of the filesystem:
> --
> storage ~ # umount /data/homes/                                              
>                                                                               
>                                                                               
>    
> storage ~ # mount /data/homes/                                               
>                                                                               
>                                                                               
>   
> storage ~ # resize2fs /dev/sdb1 
> resize2fs 1.41.9 (22-Aug-2009)  
> Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing required
> old desc_blocks = 25, new_desc_blocks = 29                                  
> Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.         
> --
> 
> These actions were take in the domU.
> 
> The patch informs the domU about the new size, but the new size is not 
> cascaded to all the levels.

You are right. This patch only sets the capacity of the device in the guest to correctly track the capacity of the corresponding device on the host side and nothing more. So in your example, I suspect if on the host side you had mounted the LVM device, and subsequently resized the device, you would see a similar behavior as you saw here (with the patch) - you may have to umount/mount to see the changes in size and this patch is not going to address this. 

Even with this restriction, I would submit it is a step in the right direction. In environments where dom0 and domu administrators are different, this patch significantly simplifies the co-ordination required to dynamically provision storage - the actions to be performed on dom0 side are independent of the actions to be performed on the domu side, and domu side may choose to do what needs to be done on the domu side when it is most convenient for the domu side.

Furthermore, applications that do not cache the metadata or applications that can be forced to re-read the metadata without having to umount/mount the device, we can have a truly dynamic environment.
> 
> I'm not familiar enough with the kernel internals to point to where the 
> missing part is.
> 
> My ideal situation would allow the folliowing to work without additional 
> steps:
> 
> dom0: lvresize -L+10G /dev/vg/foo
> domU: resizefs /dev/sdb1
> 
> (with "/dev/vg/foo" exported to domU as "/dev/sdb1")
If this worked on the native physical hardware, then I would think it would work here as well.
> 
> Right now, I need to do the following:
> dom0: lvresize -L+10G /dev/vg/foo
> domU: ls /mnt/sdb1
> domU: umount /mnt/sdb1
> domU: mount /mnt/sdb1
> domU: resizefs /dev/sdb1
> 
This is restriction imposed by the FS.
> During the 2nd attempt, when trying to umount the filesystem after 
> increasing 
> it again leads to the domU having a 100% I/O wait.

Could you give the exact steps to reproduce this problem. 

> The logs themselves do not, however, show any usefull information.
> 
> I waited for about 30 minutes and saw no change to this situation.
> 
> I am afraid that for now I will revert back to not having this patch applied 
> 
> and use the 'current' method of increasing the filesystem sizes.

Thank you for taking the time to test. Hopefully, I will be able to fix the problem you are seeing. 

Regards,

K. Y
> 
> Please let me know if there is any further testing I can help with.
> 
> --
> Joost Roeleveld
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16 21:27         ` J. Roeleveld
  2010-03-16 22:04           ` J. Roeleveld
@ 2010-03-17 15:33           ` Ky Srinivasan
  1 sibling, 0 replies; 32+ messages in thread
From: Ky Srinivasan @ 2010-03-17 15:33 UTC (permalink / raw)
  To: J. Roeleveld, xen-devel



>>> On 3/16/2010 at  5:27 PM, in message <201003162227.12625.joost@antarean.org>,
"J. Roeleveld" <joost@antarean.org> wrote: 
> On Tuesday 16 March 2010 22:24:02 J. Roeleveld wrote:
>> On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:
>> > >>> On 3/14/2010 at  9:49 AM, in message
>> >
>> > <f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>, Andrew Lyon
>> >
>> > <andrew.lyon@gmail.com> wrote:
>> > > On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org> 
> wrote:
>> > >> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> > >>> The attached patch supports dynamic resizing of vbds.
>> > >>>
>> > >>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>> > >>
>> > >> Thank you for this.
>> > >>
>> > >> The patch applied succesfully against the gentoo-xen kernel
>> > >> (2.6.29-xen-r4)
>> > >>
>> > >> I will test the patch on my system during the next week and provide
>> > >
>> > > feedback.
>> >
>> > Thanks. Looking forward to your feedback.
>> >
>> > K. Y
>> 
>> Ok, finally got time to test it.
>> Not seen any major crashes, but my domU and filesystem did end up in an
>> unusable state.
>> 
>> I also noticed that the change-entries in the logs didn't show up until I
>> "touched" the drive.
>> Eg: "ls <mount point>"
>> 
>> When trying to do an online resize, "resize2fs" refused, saying the
>>  filesystem was already using the full space:
>> --
>> storage ~ # resize2fs /dev/sdb1
>> resize2fs 1.41.9 (22-Aug-2009)
>> The filesystem is already 104857600 blocks long.  Nothing to do!
>> --
>> 
>> This was then 'resolved' by umount/mount of the filesystem:
>> --
>> storage ~ # umount /data/homes/
>> storage ~ # mount /data/homes/
>> storage ~ # resize2fs /dev/sdb1
>> resize2fs 1.41.9 (22-Aug-2009)
>> Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing
>>  required old desc_blocks = 25, new_desc_blocks = 29
>> Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.
>> --
>> 
>> These actions were take in the domU.
>> 
>> The patch informs the domU about the new size, but the new size is not
>> cascaded to all the levels.
>> 
>> I'm not familiar enough with the kernel internals to point to where the
>> missing part is.
>> 
>> My ideal situation would allow the folliowing to work without additional
>> steps:
>> 
>> dom0: lvresize -L+10G /dev/vg/foo
>> domU: resizefs /dev/sdb1
>> 
>> (with "/dev/vg/foo" exported to domU as "/dev/sdb1")
>> 
>> Right now, I need to do the following:
>> dom0: lvresize -L+10G /dev/vg/foo
>> domU: ls /mnt/sdb1
>> domU: umount /mnt/sdb1
>> domU: mount /mnt/sdb1
>> domU: resizefs /dev/sdb1
>> 
>> During the 2nd attempt, when trying to umount the filesystem after
>>  increasing it again leads to the domU having a 100% I/O wait.
>> The logs themselves do not, however, show any usefull information.
>> 
>> I waited for about 30 minutes and saw no change to this situation.
>> 
>> I am afraid that for now I will revert back to not having this patch
>>  applied and use the 'current' method of increasing the filesystem sizes.
>> 
>> Please let me know if there is any further testing I can help with.
>> 
>> --
>> Joost Roeleveld
>> 
> 
> Update,
> 
> After killing the domU, I saw the following in my dom0:
> 
> --
> VBD Resize: new size 943718400
> VBD Resize: new size 1048576000
> INFO: task blkback.3.sdb1:21647 blocked for more than 480 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> blkback.3.sdb D 0000000000000002     0 21647      2
>  ffff88002b54f550 0000000000000246 ffff88002ef08000 0000000600000000
>  ffff88002f9bf800 ffffffff806952c0 ffffffff806952c0 ffff88002eeee550
>  ffff88002b54f778 000000002eee6800 0000000000000000 ffff88002b54f778
> Call Trace:
>  [<ffffffff804d6ece>] printk+0x4e/0x58
>  [<ffffffff804d9387>] __down_read+0x101/0x119
>  [<ffffffff803d301e>] xenbus_transaction_start+0x15/0x62
>  [<ffffffff803d8843>] vbd_resize+0x50/0x120
>  [<ffffffff803d747c>] blkif_schedule+0x7e/0x4ae
>  [<ffffffff803d73fe>] blkif_schedule+0x0/0x4ae
>  [<ffffffff8023f8de>] kthread+0x47/0x73
>  [<ffffffff8020b2ea>] child_rip+0xa/0x20
>  [<ffffffff8023f897>] kthread+0x0/0x73
>  [<ffffffff8020b2e0>] child_rip+0x0/0x20
> --
Looks like the xenbus state is  corrupt - the thread servicing I/O requests on the host side is blocked on the "transaction lock". Looking at the stack, the thread did not return from the resize call. I am not sure what triggered this, but this explains the long (never-ending I/O wait you saw in the guest. Could you send me the /var/log/messages on the host when you got into this situation. 

Regards,

K. Y
> 
> (this was the result from "dmesg"
> 
> The ID of the domU was "3" and the device of the filesystem in the domU is 
> "sdb1"
> Eg. this matches the above error-message.
> 
> --
> Joost
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-03-16  3:05       ` Ky Srinivasan
@ 2010-07-20 18:27         ` Pasi Kärkkäinen
  2010-07-20 18:43           ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-07-20 18:27 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: Andrew Lyon, xen-devel, J. Roeleveld

On Mon, Mar 15, 2010 at 09:05:09PM -0600, Ky Srinivasan wrote:
> >> >
> >> 
> >> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
> >> 
> >> dom0: VBD Resize: new size 172032
> >> domU: Setting capacity to 172032
> >>
> > 
> > Btw it would be good to add the vbd-device and domU name to these log entries 
> > in the dom0,
> > and the device name in domU!
> 
> Agreed. Will send out the patch soon.
> 

Hey,

Did you send this patch? I'm just wondering if I missed it..

-- Pasi

> >  
> >> I extended the filesystem and filled up the available space, then
> >> extended again:
> >> 
> >> dom0: VBD Resize: new size 376832
> >> domU: Setting capacity to 376832
> >> 
> >> fsck, badblocks, and testing a tarball I had filled the filesystem
> >> with revealed no problems, so I decided to try reducing the
> >> filesystem, first using resize2fs, then reducing the size of the block
> >> device, although some errors were logged in domU the operation seemed
> >> to work ok:
> >> 
> >> dom0: VBD Resize: new size 114688
> >> domU: Setting capacity to 114688
> >> domU: end_request: I/O error, dev sdb1, sector 212984
> >> domU: Buffer I/O error on device sdb1, logical block 26623
> >> 
> >> I did notice that it seemed to be necessary to "poke" the device using
> >> cfdisk /dev/sdb1 before domU would notice the new size, but on the
> >> whole everything works nicely and this is a very useful new feature!
> >> 
> > 
> > Good to hear it works!
> > 
> > -- Pasi
> 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 18:27         ` Pasi Kärkkäinen
@ 2010-07-20 18:43           ` Ky Srinivasan
  2010-07-20 18:50             ` Pasi Kärkkäinen
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-07-20 18:43 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: J. Roeleveld, Andrew Lyon, xen-devel



>>> On 7/20/2010 at  2:27 PM, in message <20100720182733.GQ17817@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Mon, Mar 15, 2010 at 09:05:09PM -0600, Ky Srinivasan wrote:
>> >> >
>> >> 
>> >> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
>> >> 
>> >> dom0: VBD Resize: new size 172032
>> >> domU: Setting capacity to 172032
>> >>
>> > 
>> > Btw it would be good to add the vbd-device and domU name to these log 
> entries 
>> > in the dom0,
>> > and the device name in domU!
>> 
>> Agreed. Will send out the patch soon.
>> 
> 
> Hey,
> 
> Did you send this patch? I'm just wondering if I missed it..
> 
> -- Pasi
If I recall correctly I think I sent the patches out.

K. Y
> 
>> >  
>> >> I extended the filesystem and filled up the available space, then
>> >> extended again:
>> >> 
>> >> dom0: VBD Resize: new size 376832
>> >> domU: Setting capacity to 376832
>> >> 
>> >> fsck, badblocks, and testing a tarball I had filled the filesystem
>> >> with revealed no problems, so I decided to try reducing the
>> >> filesystem, first using resize2fs, then reducing the size of the block
>> >> device, although some errors were logged in domU the operation seemed
>> >> to work ok:
>> >> 
>> >> dom0: VBD Resize: new size 114688
>> >> domU: Setting capacity to 114688
>> >> domU: end_request: I/O error, dev sdb1, sector 212984
>> >> domU: Buffer I/O error on device sdb1, logical block 26623
>> >> 
>> >> I did notice that it seemed to be necessary to "poke" the device using
>> >> cfdisk /dev/sdb1 before domU would notice the new size, but on the
>> >> whole everything works nicely and this is a very useful new feature!
>> >> 
>> > 
>> > Good to hear it works!
>> > 
>> > -- Pasi
>> 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 18:43           ` Ky Srinivasan
@ 2010-07-20 18:50             ` Pasi Kärkkäinen
  2010-07-20 18:52               ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-07-20 18:50 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: J. Roeleveld, Andrew Lyon, xen-devel

On Tue, Jul 20, 2010 at 12:43:52PM -0600, Ky Srinivasan wrote:
> 
> 
> >>> On 7/20/2010 at  2:27 PM, in message <20100720182733.GQ17817@reaktio.net>, Pasi
> Kärkkäinen<pasik@iki.fi> wrote: 
> > On Mon, Mar 15, 2010 at 09:05:09PM -0600, Ky Srinivasan wrote:
> >> >> >
> >> >> 
> >> >> I tested the patch on xen-sources-2.6.31-r12 and it appears to work perfectly:
> >> >> 
> >> >> dom0: VBD Resize: new size 172032
> >> >> domU: Setting capacity to 172032
> >> >>
> >> > 
> >> > Btw it would be good to add the vbd-device and domU name to these log 
> > entries 
> >> > in the dom0,
> >> > and the device name in domU!
> >> 
> >> Agreed. Will send out the patch soon.
> >> 
> > 
> > Hey,
> > 
> > Did you send this patch? I'm just wondering if I missed it..
> > 
> > -- Pasi
> If I recall correctly I think I sent the patches out.
> 

Hmm.. I don't seem to be able to find them.
Care to send them again? 

-- Pasi

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 18:50             ` Pasi Kärkkäinen
@ 2010-07-20 18:52               ` Ky Srinivasan
  2010-07-20 19:00                 ` J. Roeleveld
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-07-20 18:52 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: J. Roeleveld, Andrew Lyon, xen-devel



>>> On 7/20/2010 at  2:50 PM, in message <20100720185017.GS17817@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Tue, Jul 20, 2010 at 12:43:52PM -0600, Ky Srinivasan wrote:
>> 
>> 
>> >>> On 7/20/2010 at  2:27 PM, in message <20100720182733.GQ17817@reaktio.net>, 
> Pasi
>> Kärkkäinen<pasik@iki.fi> wrote: 
>> > On Mon, Mar 15, 2010 at 09:05:09PM -0600, Ky Srinivasan wrote:
>> >> >> >
>> >> >> 
>> >> >> I tested the patch on xen-sources-2.6.31-r12 and it appears to work 
> perfectly:
>> >> >> 
>> >> >> dom0: VBD Resize: new size 172032
>> >> >> domU: Setting capacity to 172032
>> >> >>
>> >> > 
>> >> > Btw it would be good to add the vbd-device and domU name to these log 
>> > entries 
>> >> > in the dom0,
>> >> > and the device name in domU!
>> >> 
>> >> Agreed. Will send out the patch soon.
>> >> 
>> > 
>> > Hey,
>> > 
>> > Did you send this patch? I'm just wondering if I missed it..
>> > 
>> > -- Pasi
>> If I recall correctly I think I sent the patches out.
>> 
> 
> Hmm.. I don't seem to be able to find them.
> Care to send them again? 
> 
> -- Pasi

I will dig this up and send it out.

Regards,

K. Y
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 18:52               ` Ky Srinivasan
@ 2010-07-20 19:00                 ` J. Roeleveld
  2010-07-20 19:06                   ` Pasi Kärkkäinen
  0 siblings, 1 reply; 32+ messages in thread
From: J. Roeleveld @ 2010-07-20 19:00 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: Text/Plain, Size: 487 bytes --]

> >
> > Hmm.. I don't seem to be able to find them.
> > Care to send them again?
> >
> > -- Pasi
> 
> I will dig this up and send it out.
> 
> Regards,
> 
> K. Y
> 


found this in my archives:


The attached patch supports dynamic resizing of vbds. This patch fixes a bug in 
the previous version of this patch that was sent out. With this patch you can 
perform "online" resizing of  file systems that support online resizing.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>

[-- Attachment #2: xen-vbd-resize.patch --]
[-- Type: text/x-patch, Size: 4568 bytes --]

Subject: Propagate changed size of VBDs
References: bnc#583677
Patch-mainline: n/a

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>

Index: linux/drivers/xen/blkback/blkback.c
===================================================================
--- linux.orig/drivers/xen/blkback/blkback.c	2010-03-18 14:17:28.000000000 -0600
+++ linux/drivers/xen/blkback/blkback.c	2010-03-18 14:17:33.000000000 -0600
@@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
 int blkif_schedule(void *arg)
 {
 	blkif_t *blkif = arg;
+	struct vbd *vbd = &blkif->vbd;
 
 	blkif_get(blkif);
 
@@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
 	while (!kthread_should_stop()) {
 		if (try_to_freeze())
 			continue;
+		if (unlikely(vbd->size != vbd_size(vbd)))
+			vbd_resize(blkif);
 
 		wait_event_interruptible(
 			blkif->wq,
Index: linux/drivers/xen/blkback/vbd.c
===================================================================
--- linux.orig/drivers/xen/blkback/vbd.c	2010-03-18 14:17:28.000000000 -0600
+++ linux/drivers/xen/blkback/vbd.c	2010-03-18 14:17:33.000000000 -0600
@@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
 	}
 
 	vbd->bdev = bdev;
+	vbd->size = vbd_size(vbd);
 
 	if (vbd->bdev->bd_disk == NULL) {
 		DPRINTK("vbd_creat: device %08x doesn't exist.\n",
@@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req,
  out:
 	return rc;
 }
+
+void vbd_resize(blkif_t *blkif)
+{
+	struct vbd *vbd = &blkif->vbd;
+	struct xenbus_transaction xbt;
+	int err;
+	struct xenbus_device *dev = blkif->be->dev;
+	unsigned long long new_size = vbd_size(vbd);
+
+	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
+	vbd->size = new_size;
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		printk(KERN_WARNING "Error starting transaction");
+		return;
+	}
+	err = xenbus_printf(xbt, dev->nodename, "sectors", "%Lu",
+			    vbd_size(vbd));
+	if (err) {
+		printk(KERN_WARNING "Error writing new size");
+		goto abort;
+	}
+	/*
+	 * Write the current state; we will use this to synchronize
+	 * the front-end. If the current state is "connected" the
+	 * front-end will get the new size information online.
+	 */
+	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
+	if (err) {
+		printk(KERN_WARNING "Error writing the state");
+		goto abort;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err == -EAGAIN)
+		goto again;
+	if (err)
+		printk(KERN_WARNING "Error ending transaction");
+abort:
+	xenbus_transaction_end(xbt, 1);
+}
Index: linux/drivers/xen/blkback/common.h
===================================================================
--- linux.orig/drivers/xen/blkback/common.h	2010-03-18 14:17:28.000000000 -0600
+++ linux/drivers/xen/blkback/common.h	2010-03-18 14:17:33.000000000 -0600
@@ -56,6 +56,7 @@ struct vbd {
 	unsigned char  type;        /* VDISK_xxx */
 	u32            pdevice;     /* phys device that this vbd maps to */
 	struct block_device *bdev;
+	sector_t       size;        /* Cached size parameter */
 };
 
 struct backend_info;
@@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
 void blkif_disconnect(blkif_t *blkif);
 void blkif_free(blkif_t *blkif);
 int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int evtchn);
+void vbd_resize(blkif_t *blkif);
 
 #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
 #define blkif_put(_b)					\
Index: linux/drivers/xen/blkfront/blkfront.c
===================================================================
--- linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:28.000000000 -0600
+++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:33.000000000 -0600
@@ -328,9 +328,25 @@ static void connect(struct blkfront_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);
+		revalidate_disk(info->gd);
+
+		/* fall through */
+	case BLKIF_STATE_SUSPENDED:
 		return;
+	}
 
 	DPRINTK("blkfront.c:connect:%s.\n", info->xbdev->otherend);
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 19:00                 ` J. Roeleveld
@ 2010-07-20 19:06                   ` Pasi Kärkkäinen
  2010-07-28 18:59                     ` Ky Srinivasan
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-07-20 19:06 UTC (permalink / raw)
  To: J. Roeleveld; +Cc: xen-devel

On Tue, Jul 20, 2010 at 09:00:39PM +0200, J. Roeleveld wrote:
> > >
> > > Hmm.. I don't seem to be able to find them.
> > > Care to send them again?
> > >
> > > -- Pasi
> > 
> > I will dig this up and send it out.
> > 
> > Regards,
> > 
> > K. Y
> > 
> 
> 
> found this in my archives:
> 

Thanks, but unfortunately this is not the patch that adds useful 
status/resize information printing..

The patch you attached is already merged into Jeremy's xen.git kernel trees.

-- Pasi

> 
> The attached patch supports dynamic resizing of vbds. This patch fixes a bug in 
> the previous version of this patch that was sent out. With this patch you can 
> perform "online" resizing of  file systems that support online resizing.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>

> Subject: Propagate changed size of VBDs
> References: bnc#583677
> Patch-mainline: n/a
> 
> 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>
> 
> Index: linux/drivers/xen/blkback/blkback.c
> ===================================================================
> --- linux.orig/drivers/xen/blkback/blkback.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/blkback.c	2010-03-18 14:17:33.000000000 -0600
> @@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
>  int blkif_schedule(void *arg)
>  {
>  	blkif_t *blkif = arg;
> +	struct vbd *vbd = &blkif->vbd;
>  
>  	blkif_get(blkif);
>  
> @@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
>  	while (!kthread_should_stop()) {
>  		if (try_to_freeze())
>  			continue;
> +		if (unlikely(vbd->size != vbd_size(vbd)))
> +			vbd_resize(blkif);
>  
>  		wait_event_interruptible(
>  			blkif->wq,
> Index: linux/drivers/xen/blkback/vbd.c
> ===================================================================
> --- linux.orig/drivers/xen/blkback/vbd.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/vbd.c	2010-03-18 14:17:33.000000000 -0600
> @@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
>  	}
>  
>  	vbd->bdev = bdev;
> +	vbd->size = vbd_size(vbd);
>  
>  	if (vbd->bdev->bd_disk == NULL) {
>  		DPRINTK("vbd_creat: device %08x doesn't exist.\n",
> @@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req,
>   out:
>  	return rc;
>  }
> +
> +void vbd_resize(blkif_t *blkif)
> +{
> +	struct vbd *vbd = &blkif->vbd;
> +	struct xenbus_transaction xbt;
> +	int err;
> +	struct xenbus_device *dev = blkif->be->dev;
> +	unsigned long long new_size = vbd_size(vbd);
> +
> +	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
> +	vbd->size = new_size;
> +again:
> +	err = xenbus_transaction_start(&xbt);
> +	if (err) {
> +		printk(KERN_WARNING "Error starting transaction");
> +		return;
> +	}
> +	err = xenbus_printf(xbt, dev->nodename, "sectors", "%Lu",
> +			    vbd_size(vbd));
> +	if (err) {
> +		printk(KERN_WARNING "Error writing new size");
> +		goto abort;
> +	}
> +	/*
> +	 * Write the current state; we will use this to synchronize
> +	 * the front-end. If the current state is "connected" the
> +	 * front-end will get the new size information online.
> +	 */
> +	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
> +	if (err) {
> +		printk(KERN_WARNING "Error writing the state");
> +		goto abort;
> +	}
> +
> +	err = xenbus_transaction_end(xbt, 0);
> +	if (err == -EAGAIN)
> +		goto again;
> +	if (err)
> +		printk(KERN_WARNING "Error ending transaction");
> +abort:
> +	xenbus_transaction_end(xbt, 1);
> +}
> Index: linux/drivers/xen/blkback/common.h
> ===================================================================
> --- linux.orig/drivers/xen/blkback/common.h	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/common.h	2010-03-18 14:17:33.000000000 -0600
> @@ -56,6 +56,7 @@ struct vbd {
>  	unsigned char  type;        /* VDISK_xxx */
>  	u32            pdevice;     /* phys device that this vbd maps to */
>  	struct block_device *bdev;
> +	sector_t       size;        /* Cached size parameter */
>  };
>  
>  struct backend_info;
> @@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
>  void blkif_disconnect(blkif_t *blkif);
>  void blkif_free(blkif_t *blkif);
>  int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int evtchn);
> +void vbd_resize(blkif_t *blkif);
>  
>  #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
>  #define blkif_put(_b)					\
> Index: linux/drivers/xen/blkfront/blkfront.c
> ===================================================================
> --- linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:33.000000000 -0600
> @@ -328,9 +328,25 @@ static void connect(struct blkfront_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);
> +		revalidate_disk(info->gd);
> +
> +		/* fall through */
> +	case BLKIF_STATE_SUSPENDED:
>  		return;
> +	}
>  
>  	DPRINTK("blkfront.c:connect:%s.\n", info->xbdev->otherend);
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds
  2010-07-20 19:06                   ` Pasi Kärkkäinen
@ 2010-07-28 18:59                     ` Ky Srinivasan
  2010-08-15 16:20                       ` [PATCH]: Support dynamic resizing of vbds / print additional information patch Pasi Kärkkäinen
  0 siblings, 1 reply; 32+ messages in thread
From: Ky Srinivasan @ 2010-07-28 18:59 UTC (permalink / raw)
  To: J. Roeleveld, Pasi Kärkkäinen; +Cc: xen-devel

[-- Attachment #1: Type: text/plain, Size: 6714 bytes --]

Pasi,

I am attaching a patch that prints additional information when a vbd is resized. Note that on the domu side, the generic block layer already prints information on the device that is being resized.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>


>>> On 7/20/2010 at  3:06 PM, in message <20100720190656.GT17817@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Tue, Jul 20, 2010 at 09:00:39PM +0200, J. Roeleveld wrote:
>> > >
>> > > Hmm.. I don't seem to be able to find them.
>> > > Care to send them again?
>> > >
>> > > -- Pasi
>> > 
>> > I will dig this up and send it out.
>> > 
>> > Regards,
>> > 
>> > K. Y
>> > 
>> 
>> 
>> found this in my archives:
>> 
> 
> Thanks, but unfortunately this is not the patch that adds useful 
> status/resize information printing..
> 
> The patch you attached is already merged into Jeremy's xen.git kernel trees.
> 
> -- Pasi
> 
>> 
>> The attached patch supports dynamic resizing of vbds. This patch fixes a bug 
> in 
>> the previous version of this patch that was sent out. With this patch you 
> can 
>> perform "online" resizing of  file systems that support online resizing.
>> 
>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> 
>> Subject: Propagate changed size of VBDs
>> References: bnc#583677
>> Patch-mainline: n/a
>> 
>> 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>
>> 
>> Index: linux/drivers/xen/blkback/blkback.c
>> ===================================================================
>> --- linux.orig/drivers/xen/blkback/blkback.c	2010-03-18 14:17:28.000000000 -0600
>> +++ linux/drivers/xen/blkback/blkback.c	2010-03-18 14:17:33.000000000 -0600
>> @@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
>>  int blkif_schedule(void *arg)
>>  {
>>  	blkif_t *blkif = arg;
>> +	struct vbd *vbd = &blkif->vbd;
>>  
>>  	blkif_get(blkif);
>>  
>> @@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
>>  	while (!kthread_should_stop()) {
>>  		if (try_to_freeze())
>>  			continue;
>> +		if (unlikely(vbd->size != vbd_size(vbd)))
>> +			vbd_resize(blkif);
>>  
>>  		wait_event_interruptible(
>>  			blkif->wq,
>> Index: linux/drivers/xen/blkback/vbd.c
>> ===================================================================
>> --- linux.orig/drivers/xen/blkback/vbd.c	2010-03-18 14:17:28.000000000 -0600
>> +++ linux/drivers/xen/blkback/vbd.c	2010-03-18 14:17:33.000000000 -0600
>> @@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
>>  	}
>>  
>>  	vbd->bdev = bdev;
>> +	vbd->size = vbd_size(vbd);
>>  
>>  	if (vbd->bdev->bd_disk == NULL) {
>>  		DPRINTK("vbd_creat: device %08x doesn't exist.\n",
>> @@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req,
>>   out:
>>  	return rc;
>>  }
>> +
>> +void vbd_resize(blkif_t *blkif)
>> +{
>> +	struct vbd *vbd = &blkif->vbd;
>> +	struct xenbus_transaction xbt;
>> +	int err;
>> +	struct xenbus_device *dev = blkif->be->dev;
>> +	unsigned long long new_size = vbd_size(vbd);
>> +
>> +	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
>> +	vbd->size = new_size;
>> +again:
>> +	err = xenbus_transaction_start(&xbt);
>> +	if (err) {
>> +		printk(KERN_WARNING "Error starting transaction");
>> +		return;
>> +	}
>> +	err = xenbus_printf(xbt, dev->nodename, "sectors", "%Lu",
>> +			    vbd_size(vbd));
>> +	if (err) {
>> +		printk(KERN_WARNING "Error writing new size");
>> +		goto abort;
>> +	}
>> +	/*
>> +	 * Write the current state; we will use this to synchronize
>> +	 * the front-end. If the current state is "connected" the
>> +	 * front-end will get the new size information online.
>> +	 */
>> +	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
>> +	if (err) {
>> +		printk(KERN_WARNING "Error writing the state");
>> +		goto abort;
>> +	}
>> +
>> +	err = xenbus_transaction_end(xbt, 0);
>> +	if (err == -EAGAIN)
>> +		goto again;
>> +	if (err)
>> +		printk(KERN_WARNING "Error ending transaction");
>> +abort:
>> +	xenbus_transaction_end(xbt, 1);
>> +}
>> Index: linux/drivers/xen/blkback/common.h
>> ===================================================================
>> --- linux.orig/drivers/xen/blkback/common.h	2010-03-18 14:17:28.000000000 -0600
>> +++ linux/drivers/xen/blkback/common.h	2010-03-18 14:17:33.000000000 -0600
>> @@ -56,6 +56,7 @@ struct vbd {
>>  	unsigned char  type;        /* VDISK_xxx */
>>  	u32            pdevice;     /* phys device that this vbd maps to */
>>  	struct block_device *bdev;
>> +	sector_t       size;        /* Cached size parameter */
>>  };
>>  
>>  struct backend_info;
>> @@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
>>  void blkif_disconnect(blkif_t *blkif);
>>  void blkif_free(blkif_t *blkif);
>>  int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int 
> evtchn);
>> +void vbd_resize(blkif_t *blkif);
>>  
>>  #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
>>  #define blkif_put(_b)					\
>> Index: linux/drivers/xen/blkfront/blkfront.c
>> ===================================================================
>> --- linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:28.000000000 -0600
>> +++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:33.000000000 -0600
>> @@ -328,9 +328,25 @@ static void connect(struct blkfront_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);
>> +		revalidate_disk(info->gd);
>> +
>> +		/* fall through */
>> +	case BLKIF_STATE_SUSPENDED:
>>  		return;
>> +	}
>>  
>>  	DPRINTK("blkfront.c:connect:%s.\n", info->xbdev->otherend);
>>  
> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


[-- Attachment #2: online_resize_info.PATCH --]
[-- Type: text/plain, Size: 1378 bytes --]

Subject: Print additional information when a vbd is resized.

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>


Index: linux/drivers/xen/blkback/vbd.c
===================================================================
--- linux.orig/drivers/xen/blkback/vbd.c	2010-05-20 04:07:00.000000000 -0600
+++ linux/drivers/xen/blkback/vbd.c	2010-07-28 11:26:06.000000000 -0600
@@ -130,6 +130,8 @@ void vbd_resize(blkif_t *blkif)
 	struct xenbus_device *dev = blkif->be->dev;
 	unsigned long long new_size = vbd_size(vbd);
 
+	printk(KERN_INFO "VBD Resize: Domid: %d, Device: (%d, %d)\n",
+		blkif->domid, MAJOR(vbd->pdevice), MINOR(vbd->pdevice));
 	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
 	vbd->size = new_size;
 again:
Index: linux/drivers/xen/blkfront/blkfront.c
===================================================================
--- linux.orig/drivers/xen/blkfront/blkfront.c	2010-05-20 04:07:00.000000000 -0600
+++ linux/drivers/xen/blkfront/blkfront.c	2010-07-28 12:10:26.000000000 -0600
@@ -340,7 +340,7 @@ static void connect(struct blkfront_info
 				   "sectors", "%Lu", &sectors);
 		if (XENBUS_EXIST_ERR(err))
 			return;
-		printk(KERN_INFO "Setting capacity to %Lu\n",
+		printk(KERN_INFO "Changing capacity to %Lu sectors\n",
 		       sectors);
 		set_capacity(info->gd, sectors);
 		revalidate_disk(info->gd);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds / print additional information patch
  2010-07-28 18:59                     ` Ky Srinivasan
@ 2010-08-15 16:20                       ` Pasi Kärkkäinen
  2010-08-18 19:25                         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 32+ messages in thread
From: Pasi Kärkkäinen @ 2010-08-15 16:20 UTC (permalink / raw)
  To: Ky Srinivasan; +Cc: Jeremy Fitzhardinge, J. Roeleveld, xen-devel

On Wed, Jul 28, 2010 at 12:59:56PM -0600, Ky Srinivasan wrote:
> Pasi,
> 
> I am attaching a patch that prints additional information when a vbd is resized. Note that on the domu side, the generic block layer already prints information on the device that is being resized.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> 

Thanks.

Jeremy: Please merge this patch.

-- Pasi

> 
> >>> On 7/20/2010 at  3:06 PM, in message <20100720190656.GT17817@reaktio.net>, Pasi
> Kärkkäinen<pasik@iki.fi> wrote: 
> > On Tue, Jul 20, 2010 at 09:00:39PM +0200, J. Roeleveld wrote:
> >> > >
> >> > > Hmm.. I don't seem to be able to find them.
> >> > > Care to send them again?
> >> > >
> >> > > -- Pasi
> >> > 
> >> > I will dig this up and send it out.
> >> > 
> >> > Regards,
> >> > 
> >> > K. Y
> >> > 
> >> 
> >> 
> >> found this in my archives:
> >> 
> > 
> > Thanks, but unfortunately this is not the patch that adds useful 
> > status/resize information printing..
> > 
> > The patch you attached is already merged into Jeremy's xen.git kernel trees.
> > 
> > -- Pasi
> > 
> >> 
> >> The attached patch supports dynamic resizing of vbds. This patch fixes a bug 
> > in 
> >> the previous version of this patch that was sent out. With this patch you 
> > can 
> >> perform "online" resizing of  file systems that support online resizing.
> >> 
> >> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> > 
> >> Subject: Propagate changed size of VBDs
> >> References: bnc#583677
> >> Patch-mainline: n/a
> >> 
> >> 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>
> >> 
> >> Index: linux/drivers/xen/blkback/blkback.c
> >> ===================================================================
> >> --- linux.orig/drivers/xen/blkback/blkback.c	2010-03-18 14:17:28.000000000 -0600
> >> +++ linux/drivers/xen/blkback/blkback.c	2010-03-18 14:17:33.000000000 -0600
> >> @@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
> >>  int blkif_schedule(void *arg)
> >>  {
> >>  	blkif_t *blkif = arg;
> >> +	struct vbd *vbd = &blkif->vbd;
> >>  
> >>  	blkif_get(blkif);
> >>  
> >> @@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
> >>  	while (!kthread_should_stop()) {
> >>  		if (try_to_freeze())
> >>  			continue;
> >> +		if (unlikely(vbd->size != vbd_size(vbd)))
> >> +			vbd_resize(blkif);
> >>  
> >>  		wait_event_interruptible(
> >>  			blkif->wq,
> >> Index: linux/drivers/xen/blkback/vbd.c
> >> ===================================================================
> >> --- linux.orig/drivers/xen/blkback/vbd.c	2010-03-18 14:17:28.000000000 -0600
> >> +++ linux/drivers/xen/blkback/vbd.c	2010-03-18 14:17:33.000000000 -0600
> >> @@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
> >>  	}
> >>  
> >>  	vbd->bdev = bdev;
> >> +	vbd->size = vbd_size(vbd);
> >>  
> >>  	if (vbd->bdev->bd_disk == NULL) {
> >>  		DPRINTK("vbd_creat: device %08x doesn't exist.\n",
> >> @@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req,
> >>   out:
> >>  	return rc;
> >>  }
> >> +
> >> +void vbd_resize(blkif_t *blkif)
> >> +{
> >> +	struct vbd *vbd = &blkif->vbd;
> >> +	struct xenbus_transaction xbt;
> >> +	int err;
> >> +	struct xenbus_device *dev = blkif->be->dev;
> >> +	unsigned long long new_size = vbd_size(vbd);
> >> +
> >> +	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
> >> +	vbd->size = new_size;
> >> +again:
> >> +	err = xenbus_transaction_start(&xbt);
> >> +	if (err) {
> >> +		printk(KERN_WARNING "Error starting transaction");
> >> +		return;
> >> +	}
> >> +	err = xenbus_printf(xbt, dev->nodename, "sectors", "%Lu",
> >> +			    vbd_size(vbd));
> >> +	if (err) {
> >> +		printk(KERN_WARNING "Error writing new size");
> >> +		goto abort;
> >> +	}
> >> +	/*
> >> +	 * Write the current state; we will use this to synchronize
> >> +	 * the front-end. If the current state is "connected" the
> >> +	 * front-end will get the new size information online.
> >> +	 */
> >> +	err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
> >> +	if (err) {
> >> +		printk(KERN_WARNING "Error writing the state");
> >> +		goto abort;
> >> +	}
> >> +
> >> +	err = xenbus_transaction_end(xbt, 0);
> >> +	if (err == -EAGAIN)
> >> +		goto again;
> >> +	if (err)
> >> +		printk(KERN_WARNING "Error ending transaction");
> >> +abort:
> >> +	xenbus_transaction_end(xbt, 1);
> >> +}
> >> Index: linux/drivers/xen/blkback/common.h
> >> ===================================================================
> >> --- linux.orig/drivers/xen/blkback/common.h	2010-03-18 14:17:28.000000000 -0600
> >> +++ linux/drivers/xen/blkback/common.h	2010-03-18 14:17:33.000000000 -0600
> >> @@ -56,6 +56,7 @@ struct vbd {
> >>  	unsigned char  type;        /* VDISK_xxx */
> >>  	u32            pdevice;     /* phys device that this vbd maps to */
> >>  	struct block_device *bdev;
> >> +	sector_t       size;        /* Cached size parameter */
> >>  };
> >>  
> >>  struct backend_info;
> >> @@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
> >>  void blkif_disconnect(blkif_t *blkif);
> >>  void blkif_free(blkif_t *blkif);
> >>  int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int 
> > evtchn);
> >> +void vbd_resize(blkif_t *blkif);
> >>  
> >>  #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
> >>  #define blkif_put(_b)					\
> >> Index: linux/drivers/xen/blkfront/blkfront.c
> >> ===================================================================
> >> --- linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:28.000000000 -0600
> >> +++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:33.000000000 -0600
> >> @@ -328,9 +328,25 @@ static void connect(struct blkfront_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);
> >> +		revalidate_disk(info->gd);
> >> +
> >> +		/* fall through */
> >> +	case BLKIF_STATE_SUSPENDED:
> >>  		return;
> >> +	}
> >>  
> >>  	DPRINTK("blkfront.c:connect:%s.\n", info->xbdev->otherend);
> >>  
> > 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

> Subject: Print additional information when a vbd is resized.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> 
> 
> Index: linux/drivers/xen/blkback/vbd.c
> ===================================================================
> --- linux.orig/drivers/xen/blkback/vbd.c	2010-05-20 04:07:00.000000000 -0600
> +++ linux/drivers/xen/blkback/vbd.c	2010-07-28 11:26:06.000000000 -0600
> @@ -130,6 +130,8 @@ void vbd_resize(blkif_t *blkif)
>  	struct xenbus_device *dev = blkif->be->dev;
>  	unsigned long long new_size = vbd_size(vbd);
>  
> +	printk(KERN_INFO "VBD Resize: Domid: %d, Device: (%d, %d)\n",
> +		blkif->domid, MAJOR(vbd->pdevice), MINOR(vbd->pdevice));
>  	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
>  	vbd->size = new_size;
>  again:
> Index: linux/drivers/xen/blkfront/blkfront.c
> ===================================================================
> --- linux.orig/drivers/xen/blkfront/blkfront.c	2010-05-20 04:07:00.000000000 -0600
> +++ linux/drivers/xen/blkfront/blkfront.c	2010-07-28 12:10:26.000000000 -0600
> @@ -340,7 +340,7 @@ static void connect(struct blkfront_info
>  				   "sectors", "%Lu", &sectors);
>  		if (XENBUS_EXIST_ERR(err))
>  			return;
> -		printk(KERN_INFO "Setting capacity to %Lu\n",
> +		printk(KERN_INFO "Changing capacity to %Lu sectors\n",
>  		       sectors);
>  		set_capacity(info->gd, sectors);
>  		revalidate_disk(info->gd);

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH]: Support dynamic resizing of vbds / print additional information patch
  2010-08-15 16:20                       ` [PATCH]: Support dynamic resizing of vbds / print additional information patch Pasi Kärkkäinen
@ 2010-08-18 19:25                         ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 32+ messages in thread
From: Jeremy Fitzhardinge @ 2010-08-18 19:25 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ky Srinivasan, J. Roeleveld, xen-devel

 On 08/15/2010 09:20 AM, Pasi Kärkkäinen wrote:
> On Wed, Jul 28, 2010 at 12:59:56PM -0600, Ky Srinivasan wrote:
>> Pasi,
>>
>> I am attaching a patch that prints additional information when a vbd is resized. Note that on the domu side, the generic block layer already prints information on the device that is being resized.
>>
>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>>
> Thanks.
>
> Jeremy: Please merge this patch.

Done.  Well, the blkback part at least; I skipped the front bit just
because it was only a message change and I was too lazy to split it into
a separate branch...

    J

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2010-08-18 19:25 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-09 19:56 [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
2010-03-09 20:15 ` Pasi Kärkkäinen
2010-03-09 20:31   ` Ky Srinivasan
2010-03-09 20:35     ` Pasi Kärkkäinen
2010-03-09 20:39       ` Ky Srinivasan
2010-03-11 20:15         ` Pasi Kärkkäinen
2010-03-11 21:44           ` Jeremy Fitzhardinge
2010-03-11 22:01             ` Ky Srinivasan
2010-03-11 23:13               ` Jeremy Fitzhardinge
2010-03-12  2:52                 ` Ky Srinivasan
2010-03-12 10:41 ` J. Roeleveld
2010-03-14 13:49   ` Andrew Lyon
2010-03-14 14:06     ` Pasi Kärkkäinen
2010-03-16  3:04       ` Ky Srinivasan
2010-03-16  3:05       ` Ky Srinivasan
2010-07-20 18:27         ` Pasi Kärkkäinen
2010-07-20 18:43           ` Ky Srinivasan
2010-07-20 18:50             ` Pasi Kärkkäinen
2010-07-20 18:52               ` Ky Srinivasan
2010-07-20 19:00                 ` J. Roeleveld
2010-07-20 19:06                   ` Pasi Kärkkäinen
2010-07-28 18:59                     ` Ky Srinivasan
2010-08-15 16:20                       ` [PATCH]: Support dynamic resizing of vbds / print additional information patch Pasi Kärkkäinen
2010-08-18 19:25                         ` Jeremy Fitzhardinge
2010-03-16  2:50     ` [PATCH]: Support dynamic resizing of vbds Ky Srinivasan
2010-03-16 21:24       ` J. Roeleveld
2010-03-16 21:27         ` J. Roeleveld
2010-03-16 22:04           ` J. Roeleveld
2010-03-17 15:33           ` Ky Srinivasan
2010-03-17 15:09         ` Ky Srinivasan
2010-03-16  3:03     ` Ky Srinivasan
2010-03-15  9:26 ` Jan Beulich

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.