Re: Change of growing swap partition size limits?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "Hans de Goede" <hdegoede@xxxxxxxxxx> wrote:

> Radek Vykydal wrote:
> > Hi,
> > 
> > do you think we should use suggested swap size in partitioning?
> > And how?
> > 
> > How it works now:
> > -----------------
> > 
> > The only case when it is used is when the partition is set to grow 
> > without limit
> > starting at size smaller than suggested maximum - then the
> suggested
> > maximum (something like 2*ramsize) is _silently_ used both in
> kickstart
> > and ui.
> > 
> > I.e., the case for ks is:
> > - --size is smaller than suggested maximum
> > - --maxsize is not used
> > - --grow is used
> > 
> > and for ui:
> > - "Size (MB):" is smaller than suggested maximum
> > - "Fill to maximum allowable size" is selected
> > 
> > (How) do we want to change it?
> > ------------------------------
> > 
> > 1) in kickstart:
> > 
> > I think that, supposing ks install is done by people who know what
> they 
> > do, we
> > shouldn't limit the qrow based on suggested maximum. The worst thing
> is 
> > that
> > it is, and has to be, done silently because it is kickstart.
> > On the other hand, there is a workaround for our limiting - if you 
> > really want
> > to fill all remaining space with swap, use big enough --maxsize. By
> 
> > using the
> > workaround you are kind of forced to say: "Yes, I really want to do
> it".

The thing that we want  when the user specifies "--grow" in a swap line is to creat a swap that grows to a sane size ("Sane" being expressed in the function swapsuggestion function).  My point is: treating the swap lines differently from the partition lines is just common sense.  Grow in a non swap partition means: grow until maxsize, with maxsize defaulting to the available size.  and on a swap partition it means grow until maxsize, whre maxsize defaults to whatever the functions suggests (2*ram).  Is this sane, or am I just crazy?

> > 
> > 2) in ui:
> > 
> > We should at least inform user that we used the suggested maximum
> (now
> > he can only notice it in updated partition list), or perhaps better,
> let 
> > him
> > decide. I was looking at possible patch and came to 2 options:
> > 
> > A) Limit "Edit Partition" dialog. If the File System Type is swap,
> > disable the "Fill to maximum allowable size" option.
> > 
> > or
> > B) After leaving "Edit Partition" dialog with "OK", if any
> calculated
> > swap partition sizes exceed the suggested maximum due to "Fill to
> maximum
> > allowable size" selection, give a dialog like:
> > 
> > +---------------------------------------------------------+
> > | This setting would result in exceedeng of the suggested |
> > | size 666MB for these swap partitions:                   |
> > | /dev/hda3: would grow to 1500MB                         |
> > |                                                         |
> > |  Modify Partition                           Continue    |
> > +---------------------------------------------------------+
> > 

I vote for B.  Because the swap partition can be the last thing that the user is doing and he can say "please fill the rest of the HD with swap".  If he might be making a mistake, we at least warn him.

> > 
> > "Modify Partition" takes the user back to "Edit Partition" dialog,
> > "Continue" uses the exceeding values. For the just confirmed swap 
> > partitions,
> > user is never asked again. (Note that there can be ugly cases like
> when
> > two swap partitions have "Fill to maximum allowable size" selected
> > and by shrinking some other partition in "Edit Partition" you
> > make both of them exceed the suggested maximum).
> > 
> > Now, what do you think about change of partitioning wrt swap size
> > suggestion?
> > A or B?
> 
> I think A is the best, making swap partitions fill the remainder of
> the disk 
> does not seem to make much sens.

Unless remainder of the disk is sane :).  Like when 1Gig of disk remains.

> 
> > Or only in ks?
> 
> I would leave ks as is, both for compatiblity with existing ks files
> as well as 
> because in an automated install the current way of doing things makes
> some sense.
> 
> Regards,
> 
> Hans
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

-- 
Joel Andres Granados
Red Hat / Brno Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux