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

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs



Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Mon, 5 Aug 2024 00:04:42 +0200):
> On 24/07/2024 at 17:16, Pascal Hambourg wrote:
> > 
> > Poll: What should be the MIN, MAX and minimum disk size to reach MAX for
> 
> Here is a first proposal to start the discussion. The raw priority value 
> in recipes is quite obscure, and it turns out that expressing it with 
> the minimum disk size to reach MAX is not as easy as I expected, so I 
> ended up expressing the priority as a percentage of available disk space 
> (%free, not to be confused with a percentage of memory %RAM).
> 
> > - EFI partition (similar requirements as /boot for systemd-boot ?)
> > - /boot
> > - swap
> 
>        ------ old ------- | ------- new -------
>        MIN     PRIO   MAX | MIN  PRIO   MAX
> efi   538M    0%free N/A | 768M 5%free 1G
> /boot 768M    3%free 1G  | 768M 5%free 1G
> swap  100%RAM 0%free N/A | 400M 5%free 100%RAM
> 
> Rationale:
> - The ESP has the same size as /boot to support BLS/systemd-boot layout.
> - swap=RAM allows hibernation in most use cases.
> - Limit swap size to 5% disk space on small disk space with huge RAM.
> - 400M swap is ~5% of the minimum disk size (~8G).
> 
> 
> > - / in atomic recipe
> 
> * "atomic" (all in / filesystem):
>        ----- old ----- | ------- new ------
>        MIN  PRIO MAX   | MIN   PRIO    MAX
> /     900M 97%  unlim | 5G   85%free unlim
> 
>  > - / in home recipe
>  > - /home in home recipe
> 
> * "home" (separated / and /home):
>        ----- old ----- | ------- new ------
>        MIN  PRIO MAX   | MIN   PRIO    MAX
> /     1.5G 33%  30G   | 5G    5%free 100G
> /home   1G 66%  unlim | 1G   80%free unlim
> 
> Rationale:
> - 5GB / should be enough to install a desktop environment.
> - No need to limit / so much with plenty of disk space.
> - I have seen users complaining about the 30GB / being almost full.
> 
>  > - / in multi recipe
>  > - /var in multi recipe
>  > - /tmp in multi recipe (or should tmpfs be used ?)
>  > - /home in multi recipe
> 
> * "multi" (separated /, /var, /tmp and /home):
>        ----- old ----- | ------- new ------
>        MIN  PRIO MAX   | MIN   PRIO    MAX
> /       2G 18%  25G   | 4G    5%free 100G
> /var    1G  6%  10G   | 2G    2%free  40G
> /tmp  256M  1%   2G   | 512M  1%free   3G
> /home   4G 73%  unlim | 1G   77%free unlim
> 
> Rationale:
> - Same as above.
> - No need to limit /var so much with plenty of disk space.
> - There are use cases which can require a lot of space in /var 
> (databases, virtual machines...)
> - /home does not necessarily require at least 4GB. Users installing on a 
> small disk usually do not intend to store a lot of data.
> - Why should /home minimum size be bigger than in the "home" recipe ?

I think all of the above is for sure an improvement compared to what we have 
now.


> Open questions:
> 
> Is there an intended use case for built-in recipes ?
> Should there be different recipes for different uses cases ?
> E.g.:
> - minimal installation
> - workstation with graphic desktop environment
> - server

Doesn't sound like a bad idea IMO.
Could probably solve the long standing issue
"#987503 swap partition only 1 GB instead of at least 1 x RAM size"
stating that hibernation is broken for machines with RAM bigger than 1G...

> systemd >= 256~rc3-3 makes /tmp a tmpfs by default unless a mount is 
> explicitly defined. It means that atomic and home recipes do not need to 
> allocate space for /tmp in / any more. But on the other hand they may 
> need to raise the minimum swap size because tmpfs can use swap space 
> under memory pressure.
> Should the multi recipes stop creating a /tmp partition for consistency 
> with other recipes ?

Dont't know.


Holger



-- 
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


Reply to: