[PATCH]: Support dynamic resizing of vbds

[PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

[-- 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

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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
> 

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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
>> 

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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
> >> 
> 

Re: [PATCH]: Support dynamic resizing of vbds

[Jeremy Fitzhardinge]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Jeremy Fitzhardinge]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Andrew Lyon]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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
> 

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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
>> 

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

[-- 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

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

[-- 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

Re: [PATCH]: Support dynamic resizing of vbds / print additional information patch

[Pasi Kärkkäinen]

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);

Re: [PATCH]: Support dynamic resizing of vbds / print additional information patch

[Jeremy Fitzhardinge]

 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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

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

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

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

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> 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

Re: [PATCH]: Support dynamic resizing of vbds

[Jan Beulich]

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>

[PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

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

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/plain, Size: 4709 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

Re: [PATCH]: Support dynamic resizing of vbds

[Jeremy Fitzhardinge]

On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
> 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.
>    

Please send a delta against the previous patch, since it has already 
been applied.

     J

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

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



>>> On 3/18/2010 at  5:01 PM, in message <4BA294A0.1010900@goop.org>, Jeremy
Fitzhardinge <jeremy@goop.org> wrote: 
> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>> 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.
>>    
> 
> Please send a delta against the previous patch, since it has already 
> been applied.
I am attaching a new patch that is the delta on the previous one.

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




> 
>      J



[-- Attachment #2: online-resize.patch --]
[-- Type: text/plain, Size: 536 bytes --]

Index: linux/drivers/xen/blkfront/blkfront.c
===================================================================
--- linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 15:09:19.000000000 -0600
+++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 15:13:58.000000000 -0600
@@ -341,6 +341,7 @@ static void connect(struct blkfront_info
 		printk(KERN_INFO "Setting capacity to %Lu\n",
 		       sectors);
 		set_capacity(info->gd, sectors);
+		revalidate_disk(info->gd);
 
 		/* fall through */
 	case BLKIF_STATE_SUSPENDED:

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

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

Re: [PATCH]: Support dynamic resizing of vbds

[Jan Beulich]

Based on the location of the file patched, it this would seem to be 
targeted at the 2.6.18 tree, but then 2.6.18 does not have a
revalidate_disk() function (introduced only in .28). What's the deal
here? Should this perhaps be carried out by open coding in blkfront
what .28 does?

Thanks, Jan

>>> "Ky Srinivasan" <ksrinivasan@novell.com> 18.03.10 22:21 >>>


>>> On 3/18/2010 at  5:01 PM, in message <4BA294A0.1010900@goop.org>, Jeremy
Fitzhardinge <jeremy@goop.org> wrote: 
> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>> 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.
>>    
> 
> Please send a delta against the previous patch, since it has already 
> been applied.
I am attaching a new patch that is the delta on the previous one.

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




> 
>      J

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

On Monday 22 March 2010 09:47:40 Jan Beulich wrote:
> Based on the location of the file patched, it this would seem to be
> targeted at the 2.6.18 tree, but then 2.6.18 does not have a
> revalidate_disk() function (introduced only in .28). What's the deal
> here? Should this perhaps be carried out by open coding in blkfront
> what .28 does?
> 
> Thanks, Jan

Hi Jan,

These patches are based on the Suse Xen-kernel, which are based on the 2.6.30 
kernel (or in that range)
This patch applies cleanly to the xen-kernel for Gentoo which is based on 
2.6.29.
I haven't managed to test the resizing yet, this is planned for this week.

--
Joost

Re: [PATCH]: Support dynamic resizing of vbds

[Jan Beulich]

>>> "J. Roeleveld" <joost@antarean.org> 22.03.10 10:15 >>>
>On Monday 22 March 2010 09:47:40 Jan Beulich wrote:
>> Based on the location of the file patched, it this would seem to be
>> targeted at the 2.6.18 tree, but then 2.6.18 does not have a
>> revalidate_disk() function (introduced only in .28). What's the deal
>> here? Should this perhaps be carried out by open coding in blkfront
>> what .28 does?
>> 
>> Thanks, Jan
>
>Hi Jan,
>
>These patches are based on the Suse Xen-kernel, which are based on the 2.6.30 
>kernel (or in that range)
>This patch applies cleanly to the xen-kernel for Gentoo which is based on 
>2.6.29.

I understand that. But if the original patch has an issue, fixed by the
subsequently submitted one, then 2.6.18 (and other pre-.28 forward
ported kernels that would make use of the original patch) supposedly
also suffers from it, and hence also would need a respective fix.

It is btw. not clear to me whether this second patch is supposed to
address the problem you reported on March 16th, or whether that
issue is still awaiting debugging/resolution.

Jan

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

On Monday 22 March 2010 10:23:41 Jan Beulich wrote:
> >>> "J. Roeleveld" <joost@antarean.org> 22.03.10 10:15 >>>
> >
> >On Monday 22 March 2010 09:47:40 Jan Beulich wrote:
> >> Based on the location of the file patched, it this would seem to be
> >> targeted at the 2.6.18 tree, but then 2.6.18 does not have a
> >> revalidate_disk() function (introduced only in .28). What's the deal
> >> here? Should this perhaps be carried out by open coding in blkfront
> >> what .28 does?
> >>
> >> Thanks, Jan
> >
> >Hi Jan,
> >
> >These patches are based on the Suse Xen-kernel, which are based on the
> > 2.6.30 kernel (or in that range)
> >This patch applies cleanly to the xen-kernel for Gentoo which is based on
> >2.6.29.
> 
> I understand that. But if the original patch has an issue, fixed by the
> subsequently submitted one, then 2.6.18 (and other pre-.28 forward
> ported kernels that would make use of the original patch) supposedly
> also suffers from it, and hence also would need a respective fix.

True, as this patch uses a function that wasn't introduced before 2.6.28, then 
the patch would need to be applied to 2.6.28+ or one that has that function 
back-ported.

> It is btw. not clear to me whether this second patch is supposed to
> address the problem you reported on March 16th, or whether that
> issue is still awaiting debugging/resolution.

This patch was issued to also address the issue I reported.
I have not yet managed to test the patch myself due to time-constraints. 
Unless something else crops up, I should be able to test it tonight/tomorrow.

But I specify "this week" as I never know if anything else comes around till I 
actually get home.

--
Joost

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

On Mon, Mar 22, 2010 at 10:42:48AM +0100, J. Roeleveld wrote:
> On Monday 22 March 2010 10:23:41 Jan Beulich wrote:
> > >>> "J. Roeleveld" <joost@antarean.org> 22.03.10 10:15 >>>
> > >
> > >On Monday 22 March 2010 09:47:40 Jan Beulich wrote:
> > >> Based on the location of the file patched, it this would seem to be
> > >> targeted at the 2.6.18 tree, but then 2.6.18 does not have a
> > >> revalidate_disk() function (introduced only in .28). What's the deal
> > >> here? Should this perhaps be carried out by open coding in blkfront
> > >> what .28 does?
> > >>
> > >> Thanks, Jan
> > >
> > >Hi Jan,
> > >
> > >These patches are based on the Suse Xen-kernel, which are based on the
> > > 2.6.30 kernel (or in that range)
> > >This patch applies cleanly to the xen-kernel for Gentoo which is based on
> > >2.6.29.
> > 
> > I understand that. But if the original patch has an issue, fixed by the
> > subsequently submitted one, then 2.6.18 (and other pre-.28 forward
> > ported kernels that would make use of the original patch) supposedly
> > also suffers from it, and hence also would need a respective fix.
> 
> True, as this patch uses a function that wasn't introduced before 2.6.28, then 
> the patch would need to be applied to 2.6.28+ or one that has that function 
> back-ported.
> 

RHEL5 2.6.18 kernels do have SCSI online resizing support. 
Redhat guys backported it for RHEL 5.3 (2.6.18-128).

Grabbing the patches from the latest el5 kernel might help.

-- Pasi

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>> 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.
>>    
>
> Please send a delta against the previous patch, since it has already  
> been applied.
>

Btw dynamic vbd resize is something we should get into mainline Linux..

-- Pasi

Re: [PATCH]: Support dynamic resizing of vbds

[Jeremy Fitzhardinge]

On 07/20/2010 10:28 AM, Pasi Kärkkäinen wrote:
> On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
>   
>> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>>     
>>> 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.
>>>    
>>>       
>> Please send a delta against the previous patch, since it has already  
>> been applied.
>>
>>     
> Btw dynamic vbd resize is something we should get into mainline Linux..
>   

Good point.  I created a branch called "upstream/blkfront" with a
candidate set of blkfront changes to send.  Could you test it out?

Thanks,
    J

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

On Tue, Jul 20, 2010 at 10:37:51AM -0700, Jeremy Fitzhardinge wrote:
> On 07/20/2010 10:28 AM, Pasi Kärkkäinen wrote:
> > On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
> >   
> >> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
> >>     
> >>> 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.
> >>>    
> >>>       
> >> Please send a delta against the previous patch, since it has already  
> >> been applied.
> >>
> >>     
> > Btw dynamic vbd resize is something we should get into mainline Linux..
> >   
> 
> Good point.  I created a branch called "upstream/blkfront" with a
> candidate set of blkfront changes to send.  Could you test it out?
> 

Sure. I can test it tomorrow.

it seems xen/stable-2.6.32.x branch already has these patches 
so dom0 side is easy for the test..

should I try the blkfront patches against the latest Linus git tree, or 2.6.34, or ?

-- Pasi

Re: [PATCH]: Support dynamic resizing of vbds

[Jeremy Fitzhardinge]

On 07/20/2010 11:29 AM, Pasi Kärkkäinen wrote:
> On Tue, Jul 20, 2010 at 10:37:51AM -0700, Jeremy Fitzhardinge wrote:
>   
>> On 07/20/2010 10:28 AM, Pasi Kärkkäinen wrote:
>>     
>>> On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
>>>   
>>>       
>>>> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>>>>     
>>>>         
>>>>> 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.
>>>>>    
>>>>>       
>>>>>           
>>>> Please send a delta against the previous patch, since it has already  
>>>> been applied.
>>>>
>>>>     
>>>>         
>>> Btw dynamic vbd resize is something we should get into mainline Linux..
>>>   
>>>       
>> Good point.  I created a branch called "upstream/blkfront" with a
>> candidate set of blkfront changes to send.  Could you test it out?
>>
>>     
> Sure. I can test it tomorrow.
>   

Thanks.

> it seems xen/stable-2.6.32.x branch already has these patches 
> so dom0 side is easy for the test..
>
> should I try the blkfront patches against the latest Linus git tree, or 2.6.34, or ?
>   

That branch, upstream/blkfront, is rebased onto v2.6.34, so you can test
it as-is, or merge it into the current linux-2.6 branch (which is a
clean merge).

    J

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

On Tue, Jul 20, 2010 at 12:49:47PM -0700, Jeremy Fitzhardinge wrote:
> On 07/20/2010 11:29 AM, Pasi Kärkkäinen wrote:
> > On Tue, Jul 20, 2010 at 10:37:51AM -0700, Jeremy Fitzhardinge wrote:
> >   
> >> On 07/20/2010 10:28 AM, Pasi Kärkkäinen wrote:
> >>     
> >>> On Thu, Mar 18, 2010 at 02:01:20PM -0700, Jeremy Fitzhardinge wrote:
> >>>   
> >>>       
> >>>> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
> >>>>     
> >>>>         
> >>>>> 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.
> >>>>>    
> >>>>>       
> >>>>>           
> >>>> Please send a delta against the previous patch, since it has already  
> >>>> been applied.
> >>>>
> >>>>     
> >>>>         
> >>> Btw dynamic vbd resize is something we should get into mainline Linux..
> >>>   
> >>>       
> >> Good point.  I created a branch called "upstream/blkfront" with a
> >> candidate set of blkfront changes to send.  Could you test it out?
> >>
> >>     
> > Sure. I can test it tomorrow.
> >   
> 
> Thanks.
> 
> > it seems xen/stable-2.6.32.x branch already has these patches 
> > so dom0 side is easy for the test..
> >
> > should I try the blkfront patches against the latest Linus git tree, or 2.6.34, or ?
> >   
> 
> That branch, upstream/blkfront, is rebased onto v2.6.34, so you can test
> it as-is, or merge it into the current linux-2.6 branch (which is a
> clean merge).
> 

Ok, I finally got to it.

It seems to work OK for me. I installed Fedora 13 PV guest and 
updated the kernel to xen.git 'upstream/blkfront' branch (2.6.35-rc4).

Then I added 'xvdb' disk to the guest, which was 4 GB initially.
I started the guest and verified disk is 4GB in size from /proc/partitions.

And then in dom0:

# lvextend -L+1G /dev/vg_f13/resizetest2
  Extending logical volume resizetest2 to 5.00 GiB
  Logical volume resizetest2 successfully resized

Nothing in dom0 logs at this point. Nothing in domU logs either.
Then I did in the domU:

[root@resizetest1 ~]# fdisk -l /dev/xvdb

Accessing the device caused in domU dmesg:

Setting capacity to 10485760
xvdb: detected capacity change from 4294967296 to 5368709120
 xvdb: unknown partition table

[root@resizetest1 ~]# cat /proc/partitions | grep xvdb
 202       16    5242880 xvdb

So resizing seemed to work OK.
That also triggered the following in dom0 dmesg:

device vif5.0 entered promiscuous mode
virbr0: topology change detected, propagating
virbr0: port 1(vif5.0) entering forwarding state
blkback: ring-ref 8, event-channel 23, protocol 1 (x86_64-abi)
blkback: ring-ref 9, event-channel 24, protocol 1 (x86_64-abi)
vif5.0: no IPv6 routers present
VBD Resize: new size 10485760


-- Pasi

Re: [PATCH]: Support dynamic resizing of vbds

[J. Roeleveld]

On Thursday 18 March 2010 21:28:37 Ky Srinivasan wrote:
> 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>
> 

Apologies for the delay.
I finally managed to test this and the patch fixes my previous issue.

I was unable to reproduce the freeze I had with the previous patch.

--
Joost Roeleveld

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> On 4/4/2010 at  5:57 AM, in message <201004041157.16044.joost@antarean.org>,
"J. Roeleveld" <joost@antarean.org> wrote: 
> On Thursday 18 March 2010 21:28:37 Ky Srinivasan wrote:
>> 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>
>> 
> 
> Apologies for the delay.
> I finally managed to test this and the patch fixes my previous issue.
> 
> I was unable to reproduce the freeze I had with the previous patch.
Thanks.

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

Re: [PATCH]: Support dynamic resizing of vbds

[Ky Srinivasan]

>>> Jan Beulich 03/22/10 2:47 AM >>>
Based on the location of the file patched, it this would seem to be 
targeted at the 2.6.18 tree, but then 2.6.18 does not have a
revalidate_disk() function (introduced only in .28). What's the deal
here? Should this perhaps be carried out by open coding in blkfront
what .28 does?

Thanks, Jan

Jan,

This patch was tested only on the 2.6.32 kernel. For kernels that don't support revalidate_disk, we may have to implement something equivalent. I will look at this later in the week.

K. Y
>>> "Ky Srinivasan"  18.03.10 22:21 >>>


>>> On 3/18/2010 at  5:01 PM, in message <4BA294A0.1010900@goop.org>, Jeremy
Fitzhardinge  wrote: 
> On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
>> 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.
>>    
> 
> Please send a delta against the previous patch, since it has already 
> been applied.
I am attaching a new patch that is the delta on the previous one.

Signed-off-by: K. Y. Srinivasan 




> 
>      J

Re: [PATCH]: Support dynamic resizing of vbds

[Pasi Kärkkäinen]

On Mon, Mar 22, 2010 at 04:06:44PM -0600, Ky Srinivasan wrote:
> >>> Jan Beulich 03/22/10 2:47 AM >>>
> Based on the location of the file patched, it this would seem to be 
> targeted at the 2.6.18 tree, but then 2.6.18 does not have a
> revalidate_disk() function (introduced only in .28). What's the deal
> here? Should this perhaps be carried out by open coding in blkfront
> what .28 does?
> 
> Thanks, Jan
> 
> Jan,
> 
> This patch was tested only on the 2.6.32 kernel. For kernels that don't support revalidate_disk, 
> we may have to implement something equivalent. I will look at this later in the week.
> 

See my other mail in this thread.. RHEL5 2.6.18 kernel already has online resize support,
so you could grab the patches from there.

-- Pasi

> K. Y
> >>> "Ky Srinivasan"  18.03.10 22:21 >>>
> 
> 
> >>> On 3/18/2010 at  5:01 PM, in message <4BA294A0.1010900@goop.org>, Jeremy
> Fitzhardinge  wrote: 
> > On 03/18/2010 01:28 PM, Ky Srinivasan wrote:
> >> 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.
> >>    
> > 
> > Please send a delta against the previous patch, since it has already 
> > been applied.
> I am attaching a new patch that is the delta on the previous one.
> 
> Signed-off-by: K. Y. Srinivasan 
> 
> 
> 
> 
> > 
> >      J
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel