On Wed, Apr 22, 2009 at 12:16:05PM -0500, David Lehman wrote: > On Wed, 2009-04-22 at 18:51 +0200, Radek Vykydal wrote: > > David Lehman wrote: > > > On Wed, 2009-04-22 at 13:51 +0200, Radek Vykydal wrote: > > > > > >> Behaves like in F10, tested. > > >> Note that the patch dosn't fix the case when VGs are regrown > > >> (shrinked) upon editing of existing request, but that is more > > >> general bug - traceback on failure of size checks after editing > > >> of partition size. I think I'll look at it too. > > This is more troublesome than the original report. The basic thing is > that we allocate /boot and some pvs. Once the pvs are part of a vg, they > become immutable, and are no longer modified by allocatePartitions or > growPartitions. So, if the user does autopart w/ review, then tries to > create a new partition w/ size 1 and unlimited growth, that will fail > since the disks are totally allocated (/boot being a fixed size, plus > the pvs which are now immutable due to being pvs in a vg). This is > correct, IMO. So we pop up the dialog saying "not enough free space". > The next thing we do is try to back out the last changes by canceling > the actions generated by the last invocation of the partition editor > dialog. This fails when it should succeed. > > > Here's what I think is happening: We go to allocate the /boot partition > initially with size 200M. With Joel's changes from a few weeks about to > make partition allocation more flexible, we end up with a /boot that is > slightly less than 200M -- the difference being 63 sectors at the > beginning of the disk, which we used to account for explicitly. So when > we try to reallocate the original requests there is no free space region > large enough to satisfy the 200M /boot request, so the rollback fails. > > Do we need to introduce a tolerance of +/- 1MB, or should we be more > careful to actually allocate the requested size in the first place? > > Thoughts? If your refering to 2297c5facd5ad14556a362380428d261c3fd5abf. what I tried to do was to make the constraint a little bigger (2 sectors larger) so we didn't trip on some special handling that parted does for the first logical partition on an msdos label. The range depends on whatever free (partitioning.py:767) is. So if we calculate free using the initial 63 sectors, I don't think that this commit changed that behavior. Is that the commit you where talking about? Regards > > > >> > > > > > > I think the correct behavior is to not change the size of a partition > > > once it is part of a VG or an MD array. I have a patch here that filters > > > immutable partitions before calling allocatePartitions and > > > growPartitions. It might be a slight departure from F10, but it makes > > > the most sense IMO. I was going to post the patch today, but you > > > reassigned the bug to yourself and posted this one while I slept. Very > > > sneaky ;-) > > > > > > > > > > > I agree that your way is more sensible. > > To my defense, I assigned it to me from anaconda-devel-list (who > > never sleeps) - I hope it makes me a little less sneaky :) > > You are correct -- my mistake. > > > > > > > _______________________________________________ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Joel Andres Granados Brno, Czech Republic, Red Hat. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
