Radek Vykydal wrote:
Hi,
do you think we should use suggested swap size in partitioning?
And how?
First thing I'd like to see changed is how sizes are expressed. MBytes
was okay when a 1 Gbyte drive was enormous. These days, I find more
digits in partitions sizes than I can get my poor brain to comprehendand
I sometimes find myself resorting to, (gasp) pen and paper.
Can we allow three decimal digits, perhaps with a decimal point, and a
suffix? No suffix might be interpreted as at present (but maybe attract
a warning).
So, /boot 100M
/var 5G
/ 1G
/usr 2G
/var/local 2.5T
swap 1.25G
btw I do not like swap partitions. I do sometimes like to have a swap
file, so maybe
swap file:///var/swapfile 1.4 G
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".
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 think it would be worth making a reasonableness test. There's little
sillier than such a dialogue arguing the toss over 1 Mbytes. A 1.5 Gbyte
swap partition falls within the range of normal practice on modern
systems, maybe a little light on systems with several Gbytes of RAM.
OTOH 1 Tb of swap would be extraordinary.
An example of a silly question asked of me yesterday; I was enlarging an
NTFS partition. It took me longer to read the question and warning about
power failures than it took the computer to commit the changes.
"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?
Something different?
Get rid of it completely?
Or only in ks?
Thanks for your comments.
Radek
Having said all that, I don't see a clear explanation of the problem you
think exists.
Do you think swap should be allowed to grow to fill the disk? I don't
think it generally desirable. OTOH I don't think silently ignoring a
user's choice is reasonable either.
I do think a user should be able to express a range of sizes, a minimum
and a maximum. I think that is reasonable for all partitions.
Where a user has chosen a range of sizes, the minimum size should be
allocated.
If space is left over, then it should be divided up between partitions
with a separate maximum size, so as to maintain their relative maximum
sizes.
If space is still left over, it should be apportioned between partitions
with --grow specified so as to maintain their relative "maximum" sizes.
If space is still left over, it's free space.
Note that this assumes partitions can have all of minimum size, maximum
size and --grow. specified.
If the minimum allocation cannot be met, and the user cannot meet the
minimum ( not an interactive install, or chooses not to make changes),
the install fails.
Reasonableness checks should be done as/when they may, and failures are
logged (not queried) unless they mean the installation cannot be
competed (example, chosen package set won't fit). I imagine excessively
small or large swap would be logged, but used as specified. For an
interactive install, a too-large package selection would be queried, and
the user allowed to find more disk.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
