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

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

On Tue, Feb 03, 2015 at 02:51:10PM +0800, Hu Tao wrote:
> 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.
However this way is rejected once. See
https://www.redhat.com/archives/libguestfs/2014-September/msg00034.html.
I'm just having no idea what is the right way now. Looking for your
suggestions on how to do it right!

Regards,
Hu

> -----Original Message-----
> From: libguestfs-bounces@redhat.com [mailto:libguestfs-bounces@redhat.com]
On
> Behalf Of Hu Tao
> Sent: Thursday, February 26, 2015 10:25 AM
> To: Richard W.M. Jones
> Cc: Izumi, Taku/泉 拓; libguestfs@redhat.com
> Subject: Re: [Libguestfs] [PATCH v5 REBASE 0/4] virt-resize: add support
for resizing
> logical
> 
> On Tue, Feb 03, 2015 at 02:51:10PM +0800, Hu Tao wrote:
> > 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.
> 
> However this way is rejected once. See
> https://www.redhat.com/archives/libguestfs/2014-September/msg00034.html.
> I'm just having no idea what is the right way now. Looking for your
> suggestions on how to do it right!
> 
Hi, Rich

Could you please give us some hints on this?

Regards,
- Chen