On Thu, 2012-12-13 at 16:19 -0700, Chris Murphy wrote:
> On Dec 13, 2012, at 3:57 PM, Adam Williamson <awilliam@xxxxxxxxxx>
> wrote:
>
> > topart' does not shrink anything. If you're going to shrink a
> > partition the only way is interactively, either via the 'guided'
> > free-up-space dialog, or custom part.
>
> I'm considering "not custom" as "autopart" because I have almost no
> choices or customization. It is automatically repartitioning based on
> the single input I've given which is whether to shrink or delete the
> Windows volume. In this case shrink.
We don't really have consistent terminology yet, but 'autopart' is a
specific thing: a chunk of code in anaconda which automatically defines
a set of partitions for a Fedora installation in empty space. That's
_all_ it does. So please use 'autopart' to refer to that. Both the
'guided' and 'custom' - my current terms for the two - paths can call
the 'autopart' algorithm: 'guided' does it unavoidably once you've freed
up space for the install, 'custom' will use it if you click the 'Create
partitions for me' button.
> > So I think the big change in behaviour here - which somehow I hadn't
> > quite grokked before - is that, in the non-custom ('guided')
> workflow in
> > F18, you don't get any opportunity to decide how much shrinking to
> do.
>
> There are a number of departures between the newUI mockups and
> reality, Reclaim Disk Space is one of the biggest "sleeper"
> differences. However, I thought a while ago there was a way to set the
> percentage, it just was non-obvious what I was doing with it.
I checked back to Beta, and it seems to be the same there, I didn't see
an option to set a size.
> > I know we're pretty late here, but we may need to do some lobbying
> of
> > the anaconda team to do something about this. The current non-custom
> > shrink option seems almost worse than not having one at all.
>
> Setting aside the breaking of the Windows volume (an obvious blocker),
> at a minimum the default needs to be limited to something like 25% of
> the Windows volume's free space (instead of 98%), especially
> considering it's ambiguous what the percentage is even referring to.
> So it needs to be safe, even if user resizing is (re)integrated.
anaconda doesn't really 'think' in terms of percentages, that's just a
representation used for the user in the 'reclaim space' dialog. What
anaconda's code really does is set a lower bound on the size of the
partition after shrinking, which is the smallest possible size the
shrink tool reports to be possible, plus a pad factor which is the
smaller of 500MB or 10% of the size of the partition. This part isn't
new code: in oldUI, this number represented the smallest size you could
choose for the resized partition. In newUI, it's simply The Size You
Get, you have no option to set a bigger size (unless you're in custom
part. I think. I haven't actually checked yet that custom part lets you
specify a size, but I'm assuming it does, so far.)
The problem with introducing a concept of what's 'safe' for a 'Windows
partition' is those are two somewhat squishy concepts we don't currently
really have. anaconda's resize function isn't really considering
'Windows partition' and 'Linux partition' and 'data partition' and
whatever. It just sees partitions. A partition's a partition. So your
suggestion would involve trying to tell the resize algorithm when it's
dealing with a 'Windows partition' and when it isn't, which seems like
possibly unwarranted complexity. The concept of 'safe' is similarly
rather complex - how much free space *is* safe for a Windows install? Is
it the same for all Windows installs? To what extent is it a factor of
the Windows version, the size of the disk, etc?
oldUI didn't do any of this, it just gave you a range from 'current
size' down to 'smallest viable size' and let you knock yourself out. I
think that behaviour would still be okay for newUI.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
