Xen devel - Mar 2010 - [PATCH]: Support dynamic resizing of vbds

The attached patch supports dynamic resizing of vbds.

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




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

On Tue, Mar 09, 2010 at 12:56:11PM -0700, Ky Srinivasan
wrote:
> The attached patch supports dynamic resizing of vbds.
> 
Nice! Did you also implement the xm/xend side of resizing? 

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

-- Pasi


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

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

Regards,

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

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

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

-- Pasi
> Regards,
> 
> K. Y
> > 
> > I implemented xm/xend support for online resizing a couple of months
ago,
> > but I was not done with the blkback/blkfront code yet.. well, no need
for
> > that now :)
> > 
> > -- Pasi
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

Regards,

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

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

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
> >> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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

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

Regards,

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

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

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

     J

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

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

Regards,

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

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

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

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

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

--
Joost Roeleveld

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

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

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

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

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

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

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

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

Andy

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

On Sun, Mar 14, 2010 at 01:49:38PM +0000, Andrew Lyon
wrote:
> On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld <joost@antarean.org>
wrote:
> > On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
> >> The attached patch supports dynamic resizing of vbds.
> >>
> >> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> >>
> >
> > Thank you for this.
> >
> > The patch applied succesfully against the gentoo-xen kernel
(2.6.29-xen-r4)
> >
> > I will test the patch on my system during the next week and provide
feedback.
> >
> > --
> > Joost Roeleveld
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> 
> I tested the patch on xen-sources-2.6.31-r12 and it appears to work
perfectly:
> 
> dom0: VBD Resize: new size 172032
> domU: Setting capacity to 172032
>
Btw it would be good to add the vbd-device and domU name to these log entries in
the dom0,
and the device name in domU!
 
> I extended the filesystem and filled up the available space, then
> extended again:
> 
> dom0: VBD Resize: new size 376832
> domU: Setting capacity to 376832
> 
> fsck, badblocks, and testing a tarball I had filled the filesystem
> with revealed no problems, so I decided to try reducing the
> filesystem, first using resize2fs, then reducing the size of the block
> device, although some errors were logged in domU the operation seemed
> to work ok:
> 
> dom0: VBD Resize: new size 114688
> domU: Setting capacity to 114688
> domU: end_request: I/O error, dev sdb1, sector 212984
> domU: Buffer I/O error on device sdb1, logical block 26623
> 
> I did notice that it seemed to be necessary to "poke" the device
using
> cfdisk /dev/sdb1 before domU would notice the new size, but on the
> whole everything works nicely and this is a very useful new feature!
> 
Good to hear it works!

-- Pasi


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

Keir,

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

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

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




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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

These actions were take in the domU.

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

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

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

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

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

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

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

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

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

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

--
Joost Roeleveld

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

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

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

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

(this was the result from "dmesg"

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

--
Joost

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

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

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

--
Joost

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

>>> On 3/16/2010 at  5:24 PM, in message
<201003162224.02105.joost@antarean.org>,
"J. Roeleveld" <joost@antarean.org> wrote:
> On Tuesday 16 March 2010 03:50:18 Ky Srinivasan wrote:
>> >>> On 3/14/2010 at  9:49 AM, in message
>> 
>> <f4527be1003140649p6d9cced6u7d1fde07897ae70c@mail.gmail.com>,
Andrew Lyon
>> 
>> <andrew.lyon@gmail.com> wrote:
>> > On Fri, Mar 12, 2010 at 10:41 AM, J. Roeleveld
<joost@antarean.org> wrote:
>> >> On Tuesday 09 March 2010 20:56:11 Ky Srinivasan wrote:
>> >>> The attached patch supports dynamic resizing of vbds.
>> >>>
>> >>> Signed-off-by: K. Y. Srinivasan
<ksrinivasan@novell.com>
>> >>
>> >> Thank you for this.
>> >>
>> >> The patch applied succesfully against the gentoo-xen kernel
>> >> (2.6.29-xen-r4)
>> >>
>> >> I will test the patch on my system during the next week and
provide
>> >
>> > feedback.
>> 
>> Thanks. Looking forward to your feedback.
>> 
>> K. Y
> 
> Ok, finally got time to test it.
> Not seen any major crashes, but my domU and filesystem did end up in an 
> unusable state.
> 
> I also noticed that the change-entries in the logs didn''t show up
until I
> "touched" the drive.
> Eg: "ls <mount point>"
This is by design. The change made to the device on the host will be propagated
to the device in the guest in the context of the dedicated thread in the host
that services I/O requests for the device under question. If there is any
activity on the device the size information (if it has changed) will be
propagated to the guest.
> 
> When trying to do an online resize, "resize2fs" refused, saying
the
> filesystem 
> was already using the full space:
> --
> storage ~ # resize2fs /dev/sdb1   
> resize2fs 1.41.9 (22-Aug-2009)    
> The filesystem is already 104857600 blocks long.  Nothing to do!
> --
> 
> This was then ''resolved'' by umount/mount of the
filesystem:
> --
> storage ~ # umount /data/homes/
>
>
>    
> storage ~ # mount /data/homes/
>
>
>   
> storage ~ # resize2fs /dev/sdb1 
> resize2fs 1.41.9 (22-Aug-2009)  
> Filesystem at /dev/sdb1 is mounted on /data/homes; on-line resizing
required
> old desc_blocks = 25, new_desc_blocks = 29
> Performing an on-line resize of /dev/sdb1 to 117964800 (4k) blocks.
> --
> 
> These actions were take in the domU.
> 
> The patch informs the domU about the new size, but the new size is not 
> cascaded to all the levels.
You are right. This patch only sets the capacity of the device in the guest to
correctly track the capacity of the corresponding device on the host side and
nothing more. So in your example, I suspect if on the host side you had mounted
the LVM device, and subsequently resized the device, you would see a similar
behavior as you saw here (with the patch) - you may have to umount/mount to see
the changes in size and this patch is not going to address this.

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

Furthermore, applications that do not cache the metadata or applications that
can be forced to re-read the metadata without having to umount/mount the device,
we can have a truly dynamic environment.
> 
> I''m not familiar enough with the kernel internals to point to
where the
> missing part is.
> 
> My ideal situation would allow the folliowing to work without additional 
> steps:
> 
> dom0: lvresize -L+10G /dev/vg/foo
> domU: resizefs /dev/sdb1
> 
> (with "/dev/vg/foo" exported to domU as "/dev/sdb1")
If this worked on the native physical hardware, then I would think it would work
here as well.
> 
> Right now, I need to do the following:
> dom0: lvresize -L+10G /dev/vg/foo
> domU: ls /mnt/sdb1
> domU: umount /mnt/sdb1
> domU: mount /mnt/sdb1
> domU: resizefs /dev/sdb1
> 
This is restriction imposed by the FS.
> During the 2nd attempt, when trying to umount the filesystem after 
> increasing 
> it again leads to the domU having a 100% I/O wait.
Could you give the exact steps to reproduce this problem. 
> The logs themselves do not, however, show any usefull information.
> 
> I waited for about 30 minutes and saw no change to this situation.
> 
> I am afraid that for now I will revert back to not having this patch
applied
> 
> and use the ''current'' method of increasing the filesystem
sizes.
Thank you for taking the time to test. Hopefully, I will be able to fix the
problem you are seeing.

Regards,

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

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

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

Regards,

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

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

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>





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

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

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

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



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

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



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

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

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

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


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

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

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

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


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

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



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

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


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

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


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

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


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

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

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

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
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


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

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

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

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

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

-- Pasi


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

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

Regards,

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

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

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


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

On Tue, Jul 20, 2010 at 09:00:39PM +0200, J. Roeleveld
wrote:
> > >
> > > Hmm.. I don''t seem to be able to find them.
> > > Care to send them again?
> > >
> > > -- Pasi
> > 
> > I will dig this up and send it out.
> > 
> > Regards,
> > 
> > K. Y
> > 
> 
> 
> found this in my archives:
> 
Thanks, but unfortunately this is not the patch that adds useful 
status/resize information printing..

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

-- Pasi
> 
> The attached patch supports dynamic resizing of vbds. This patch fixes a
bug in
> the previous version of this patch that was sent out. With this patch you
can
> perform "online" resizing of  file systems that support online
resizing.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> Subject: Propagate changed size of VBDs
> References: bnc#583677
> Patch-mainline: n/a
> 
> Support dynamic resizing of virtual block devices. This patch supports
> both file backed block devices as well as physical devices that can be
> dynamically resized on the host side.
> 
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
> 
> Index: linux/drivers/xen/blkback/blkback.c
> ==================================================================> ---
linux.orig/drivers/xen/blkback/blkback.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/blkback.c	2010-03-18 14:17:33.000000000 -0600
> @@ -209,6 +209,7 @@ static void print_stats(blkif_t *blkif)
>  int blkif_schedule(void *arg)
>  {
>  	blkif_t *blkif = arg;
> +	struct vbd *vbd = &blkif->vbd;
>  
>  	blkif_get(blkif);
>  
> @@ -218,6 +219,8 @@ int blkif_schedule(void *arg)
>  	while (!kthread_should_stop()) {
>  		if (try_to_freeze())
>  			continue;
> +		if (unlikely(vbd->size != vbd_size(vbd)))
> +			vbd_resize(blkif);
>  
>  		wait_event_interruptible(
>  			blkif->wq,
> Index: linux/drivers/xen/blkback/vbd.c
> ==================================================================> ---
linux.orig/drivers/xen/blkback/vbd.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/vbd.c	2010-03-18 14:17:33.000000000 -0600
> @@ -73,6 +73,7 @@ int vbd_create(blkif_t *blkif, blkif_vde
>  	}
>  
>  	vbd->bdev = bdev;
> +	vbd->size = vbd_size(vbd);
>  
>  	if (vbd->bdev->bd_disk == NULL) {
>  		DPRINTK("vbd_creat: device %08x doesn''t exist.\n",
> @@ -120,3 +121,45 @@ int vbd_translate(struct phys_req *req,
>   out:
>  	return rc;
>  }
> +
> +void vbd_resize(blkif_t *blkif)
> +{
> +	struct vbd *vbd = &blkif->vbd;
> +	struct xenbus_transaction xbt;
> +	int err;
> +	struct xenbus_device *dev = blkif->be->dev;
> +	unsigned long long new_size = vbd_size(vbd);
> +
> +	printk(KERN_INFO "VBD Resize: new size %Lu\n", new_size);
> +	vbd->size = new_size;
> +again:
> +	err = xenbus_transaction_start(&xbt);
> +	if (err) {
> +		printk(KERN_WARNING "Error starting transaction");
> +		return;
> +	}
> +	err = xenbus_printf(xbt, dev->nodename, "sectors",
"%Lu",
> +			    vbd_size(vbd));
> +	if (err) {
> +		printk(KERN_WARNING "Error writing new size");
> +		goto abort;
> +	}
> +	/*
> +	 * Write the current state; we will use this to synchronize
> +	 * the front-end. If the current state is "connected" the
> +	 * front-end will get the new size information online.
> +	 */
> +	err = xenbus_printf(xbt, dev->nodename, "state",
"%d", dev->state);
> +	if (err) {
> +		printk(KERN_WARNING "Error writing the state");
> +		goto abort;
> +	}
> +
> +	err = xenbus_transaction_end(xbt, 0);
> +	if (err == -EAGAIN)
> +		goto again;
> +	if (err)
> +		printk(KERN_WARNING "Error ending transaction");
> +abort:
> +	xenbus_transaction_end(xbt, 1);
> +}
> Index: linux/drivers/xen/blkback/common.h
> ==================================================================> ---
linux.orig/drivers/xen/blkback/common.h	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkback/common.h	2010-03-18 14:17:33.000000000 -0600
> @@ -56,6 +56,7 @@ struct vbd {
>  	unsigned char  type;        /* VDISK_xxx */
>  	u32            pdevice;     /* phys device that this vbd maps to */
>  	struct block_device *bdev;
> +	sector_t       size;        /* Cached size parameter */
>  };
>  
>  struct backend_info;
> @@ -116,6 +117,7 @@ blkif_t *blkif_alloc(domid_t domid);
>  void blkif_disconnect(blkif_t *blkif);
>  void blkif_free(blkif_t *blkif);
>  int blkif_map(blkif_t *blkif, unsigned long shared_page, unsigned int
evtchn);
> +void vbd_resize(blkif_t *blkif);
>  
>  #define blkif_get(_b) (atomic_inc(&(_b)->refcnt))
>  #define blkif_put(_b)					\
> Index: linux/drivers/xen/blkfront/blkfront.c
> ==================================================================> ---
linux.orig/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:28.000000000 -0600
> +++ linux/drivers/xen/blkfront/blkfront.c	2010-03-18 14:17:33.000000000
-0600
> @@ -328,9 +328,25 @@ static void connect(struct blkfront_info
>  	unsigned int binfo;
>  	int err;
>  
> -	if ((info->connected == BLKIF_STATE_CONNECTED) ||
> -	    (info->connected == BLKIF_STATE_SUSPENDED) )
> +	switch (info->connected) {
> +	case BLKIF_STATE_CONNECTED:
> +		/*
> +		 * Potentially, the back-end may be signalling
> +		 * a capacity change; update the capacity.
> +		 */
> +		err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +				   "sectors", "%Lu", &sectors);
> +		if (XENBUS_EXIST_ERR(err))
> +			return;
> +		printk(KERN_INFO "Setting capacity to %Lu\n",
> +		       sectors);
> +		set_capacity(info->gd, sectors);
> +		revalidate_disk(info->gd);
> +
> +		/* fall through */
> +	case BLKIF_STATE_SUSPENDED:
>  		return;
> +	}
>  
>  	DPRINTK("blkfront.c:connect:%s.\n",
info->xbdev->otherend);
>  
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

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

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

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



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

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


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

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

Jeremy: Please merge this patch.

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

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

On 08/15/2010 09:20 AM, Pasi Kärkkäinen wrote:
> On Wed, Jul 28, 2010 at 12:59:56PM -0600, Ky Srinivasan wrote:
>> Pasi,
>>
>> I am attaching a patch that prints additional information when a vbd is
resized. Note that on the domu side, the generic block layer already prints
information on the device that is being resized.
>>
>> Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
>>
> Thanks.
>
> Jeremy: Please merge this patch.
Done.  Well, the blkback part at least; I skipped the front bit just
because it was only a message change and I was too lazy to split it into
a separate branch...

    J

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