[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Trigger xen_vbd_resize



On Fri, Aug 16, 2013 at 07:23:53AM -0700, Steve Prochniak wrote:
> The piece that I'm missing comes before all that.  

Adding xen-devel back so that other interested parties can benefit from
this knowledge.

> 
> In dom0, I use dd to expand my disk.img file.  I see that in 
> xen_blkif_schedule we check to see if the disk size changed using vbd_sz as 
> you mentioned.  But how do we get from doing the dd to executing that code 
> path in blkback?
> 
> I see that backend_changed in xenbus will indirectly call xen_blkif_schedule, 
> but nothing about doing a dd in dom0 is going to trigger a callback to 
> backend_changed.  What's the proper way for me to signal this?
> 
> All of the examples of people using dynamically resizing disks that I can 
> find are using LVM, but we are using a simple file.
> 
> disk = ['file:/OVS/OVM_OL6U4_X86_PVM_2GB/System.img,xvda,w',
>         'file:/OVS/OVM_OL6U4_X86_PVM_2GB/Disk.img,xvdb,w']
> 

If you look in the loop.c file you will see this:

        case LOOP_SET_CAPACITY:                                                 
                err = -EPERM;                                                   
                if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))             
                        err = loop_set_capacity(lo, bdev);                      
                break;                                            

which ends up calling figure_loop_size which calls 
        set_capacity(lo->lo_disk, x);                                           


In blkback there is xen_blkif_schedule which is a thread running
all the time servicing the guest fronted for its I/Os which does:

             while (!kthread_should_stop()) {                                   
     
                if (try_to_freeze())                                            
                        continue;                                               
                if (unlikely(vbd->size != vbd_sz(vbd)))                         
                        xen_vbd_resize(blkif);                

Every time there is an request it will trigger the check to see if it
needs to resize the disk.

Doing a google search for LOOP_SET_CAPACITY tells me that losetup might
have this implemented, and sure enough  in the manpage of losetup you will see:

     Resize loop device:

            losetup -c loopdev



Hopefully this helps.
> Steve 
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk 
> Sent: Thursday, August 15, 2013 4:18 PM
> To: Steve Prochniak
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Trigger xen_vbd_resize
> 
> On Thu, Aug 15, 2013 at 09:03:11AM -0700, Steve Prochniak wrote:
> > I can see that there is support for dynamically resizing of virtual disks 
> > in blockback, but how do I trigger 
> > backend_changed->xen_blkif_schedule->xen_vbd_resize() when I use something 
> > like dd to expand my file backed storage?
> 
> That would imply you are using the loop back device. If you look in the
> blkback driver you will see that it checks on every request that:
> 
> #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
>                          (_v)->bdev->bd_part->nr_sects : \
>                           get_capacity((_v)->bdev->bd_disk))
> 
> And if you follow get_capacity, you get to:
> 
> static inline sector_t get_capacity(struct gendisk *disk)
> {
>         return disk->part0.nr_sects;
> }
> 
> Looking in the loop device.. well, I will let you figure this out -
> hint: figure_loop_size
> 
> 
> > 
> >  
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.