Re: [PATCH]: Support dynamic resizing of vbds

["J. Roeleveld" <joost@antarean.org>]

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