Libguestfs - Jan 2015 - Re: [PATCH v5 REBASE 0/4] virt-resize: add support for resizing logical

On Wed, Dec 17, 2014 at 03:07:11PM +0800, Hu Tao wrote:
> On Thu, Oct 30, 2014 at 10:46:52AM +0800, Hu Tao wrote:
> > Hi Rich,
> > 
> > This is rebase of v5 series. Meanwhile, I found a bug when shrinking
> > partitions, and the fix is incuded in this version (patch 2).
> 
> Hi,
> 
> When support to resizing logical partitions is enabled, there is a
> problem about resizing the extended partition: whether the extended
> partition is automatically resized (expanded or shrunk) by virt-resize
> based on the resizing of logical partitions?
> 
> All the cases can be categorized as these two:
> 
> 1. user doesn't explictly resize the extended partition. In this case
it
>    seems reasonable to automatically expand the extended partition as well.
> 
> 2. user explictly resizes the extended partition. If the extended
>    partition is resized as user requested, then we should deal with the
>    conflicts about resizing extended partition and logical partitions,
>    this is somewhat tricky in the current implementation; But if the
>    extended partition is automatically resized, user will be confused as
>    the resulting size may be what he/she expects.
s/may be/may not be/

I think the best choice is:

1. If user doesn't explictly resize the extended partition, then any
   resizing (expanding or shrinking) of logical partitions will cause
   the automatical resizing of the extended partition.

2. If user explictly resize the extended partition, then any confliction
   between resizing of the extended partition and logical partitions
   will raise an error.

To achieve this, the patchset needs to be refactored heavily. So I'd
like to hear suggestions before starting refactor.

Regards,
Hu

On Wed, Jan 28, 2015 at 02:24:15PM +0800, Hu Tao wrote:
> On Wed, Dec 17, 2014 at 03:07:11PM +0800, Hu Tao wrote:
> > On Thu, Oct 30, 2014 at 10:46:52AM +0800, Hu Tao wrote:
> > > Hi Rich,
> > > 
> > > This is rebase of v5 series. Meanwhile, I found a bug when
shrinking
> > > partitions, and the fix is incuded in this version (patch 2).
> > 
> > Hi,
> > 
> > When support to resizing logical partitions is enabled, there is a
> > problem about resizing the extended partition: whether the extended
> > partition is automatically resized (expanded or shrunk) by virt-resize
> > based on the resizing of logical partitions?
> > 
> > All the cases can be categorized as these two:
> > 
> > 1. user doesn't explictly resize the extended partition. In this
case it
> >    seems reasonable to automatically expand the extended partition as
well.
> > 
> > 2. user explictly resizes the extended partition. If the extended
> >    partition is resized as user requested, then we should deal with
the
> >    conflicts about resizing extended partition and logical partitions,
> >    this is somewhat tricky in the current implementation; But if the
> >    extended partition is automatically resized, user will be confused
as
> >    the resulting size may be what he/she expects.
> 
> s/may be/may not be/
> 
> I think the best choice is:
> 
> 1. If user doesn't explictly resize the extended partition, then any
>    resizing (expanding or shrinking) of logical partitions will cause
>    the automatical resizing of the extended partition.
> 
> 2. If user explictly resize the extended partition, then any confliction
>    between resizing of the extended partition and logical partitions
>    will raise an error.
> 
> To achieve this, the patchset needs to be refactored heavily. So I'd
> like to hear suggestions before starting refactor.
Part of the problem I have with the original patch set is really
nothing to do with this user input question.  It's that the patches
don't model properly how the extended partition and logical partitions
actually work.  There is one partition which is nominated as the
extended partition (EP), and then logical partitions (LP) live inside
that EP.  At the moment we just have a list of partitions and list of
LPs.

(The other part is that these are still high risk patches that are
likely to break virt-resize than do anything useful.  It would IMO be
better to discourage people from using logical partitions in the first
place, especially since a good alternative -- GPT -- exists.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On Wed, Jan 28, 2015 at 03:43:19PM +0000, Richard W.M. Jones
wrote:
> On Wed, Jan 28, 2015 at 02:24:15PM +0800, Hu Tao wrote:
> > On Wed, Dec 17, 2014 at 03:07:11PM +0800, Hu Tao wrote:
> > > On Thu, Oct 30, 2014 at 10:46:52AM +0800, Hu Tao wrote:
> > > > Hi Rich,
> > > > 
> > > > This is rebase of v5 series. Meanwhile, I found a bug when
shrinking
> > > > partitions, and the fix is incuded in this version (patch
2).
> > > 
> > > Hi,
> > > 
> > > When support to resizing logical partitions is enabled, there is
a
> > > problem about resizing the extended partition: whether the
extended
> > > partition is automatically resized (expanded or shrunk) by
virt-resize
> > > based on the resizing of logical partitions?
> > > 
> > > All the cases can be categorized as these two:
> > > 
> > > 1. user doesn't explictly resize the extended partition. In
this case it
> > >    seems reasonable to automatically expand the extended
partition as well.
> > > 
> > > 2. user explictly resizes the extended partition. If the extended
> > >    partition is resized as user requested, then we should deal
with the
> > >    conflicts about resizing extended partition and logical
partitions,
> > >    this is somewhat tricky in the current implementation; But if
the
> > >    extended partition is automatically resized, user will be
confused as
> > >    the resulting size may be what he/she expects.
> > 
> > s/may be/may not be/
> > 
> > I think the best choice is:
> > 
> > 1. If user doesn't explictly resize the extended partition, then
any
> >    resizing (expanding or shrinking) of logical partitions will cause
> >    the automatical resizing of the extended partition.
> > 
> > 2. If user explictly resize the extended partition, then any
confliction
> >    between resizing of the extended partition and logical partitions
> >    will raise an error.
> > 
> > To achieve this, the patchset needs to be refactored heavily. So
I'd
> > like to hear suggestions before starting refactor.
> 
> Part of the problem I have with the original patch set is really
> nothing to do with this user input question.  It's that the patches
> don't model properly how the extended partition and logical partitions
> actually work.  There is one partition which is nominated as the
> extended partition (EP), and then logical partitions (LP) live inside
> that EP.  At the moment we just have a list of partitions and list of
> LPs.
Agreed.
> 
> (The other part is that these are still high risk patches that are
> likely to break virt-resize than do anything useful.  It would IMO be
> better to discourage people from using logical partitions in the first
> place, especially since a good alternative -- GPT -- exists.)
Can I read you as you are rejecting any efforts to add support of
resizing logical partitions? I admit that GPT is better, but I'm not
sure we can abandon MBR partitions immediately, there may be old systems
running on VMs that do not support GPT.

Regards,
Hu

On Wed, Jan 28, 2015 at 03:43:19PM +0000, Richard W.M. Jones
wrote:
> On Wed, Jan 28, 2015 at 02:24:15PM +0800, Hu Tao wrote:
> > On Wed, Dec 17, 2014 at 03:07:11PM +0800, Hu Tao wrote:
> > > On Thu, Oct 30, 2014 at 10:46:52AM +0800, Hu Tao wrote:
> > > > Hi Rich,
> > > > 
> > > > This is rebase of v5 series. Meanwhile, I found a bug when
shrinking
> > > > partitions, and the fix is incuded in this version (patch
2).
> > > 
> > > Hi,
> > > 
> > > When support to resizing logical partitions is enabled, there is
a
> > > problem about resizing the extended partition: whether the
extended
> > > partition is automatically resized (expanded or shrunk) by
virt-resize
> > > based on the resizing of logical partitions?
> > > 
> > > All the cases can be categorized as these two:
> > > 
> > > 1. user doesn't explictly resize the extended partition. In
this case it
> > >    seems reasonable to automatically expand the extended
partition as well.
> > > 
> > > 2. user explictly resizes the extended partition. If the extended
> > >    partition is resized as user requested, then we should deal
with the
> > >    conflicts about resizing extended partition and logical
partitions,
> > >    this is somewhat tricky in the current implementation; But if
the
> > >    extended partition is automatically resized, user will be
confused as
> > >    the resulting size may be what he/she expects.
> > 
> > s/may be/may not be/
> > 
> > I think the best choice is:
> > 
> > 1. If user doesn't explictly resize the extended partition, then
any
> >    resizing (expanding or shrinking) of logical partitions will cause
> >    the automatical resizing of the extended partition.
> > 
> > 2. If user explictly resize the extended partition, then any
confliction
> >    between resizing of the extended partition and logical partitions
> >    will raise an error.
> > 
> > To achieve this, the patchset needs to be refactored heavily. So
I'd
> > like to hear suggestions before starting refactor.
> 
> Part of the problem I have with the original patch set is really
> nothing to do with this user input question.  It's that the patches
> don't model properly how the extended partition and logical partitions
> actually work.  There is one partition which is nominated as the
> extended partition (EP), and then logical partitions (LP) live inside
> that EP.  At the moment we just have a list of partitions and list of
> LPs.
Do you have any idea about modelling EP and LPs?

What I can think of is adding a type extended_partition which is similar
to type partition, except that it has a member partitions of type
partition list to hold logical partitions.

Type extended_partition is better to inherit from type partition, but I
don't know how to do it in OCaml.

Regards,
Hu
> 
> (The other part is that these are still high risk patches that are
> likely to break virt-resize than do anything useful.  It would IMO be
> better to discourage people from using logical partitions in the first
> place, especially since a good alternative -- GPT -- exists.)
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW