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".
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 | +---------------------------------------------------------+
"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
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?
- 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".
- 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 | +---------------------------------------------------------+
"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.
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
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?
- 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".
- 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.
anaconda-devel@lists.fedoraproject.org