Pascal Hambourg <pas...@plouf.fr.eu.org> writes: > On 18/08/2024 à 16:00, Philip Hands wrote: >> >> If the disk they're installing onto is huge, then having the upper limit >> for /boot be 0.5GB larger will go unnoticed, whereas running out of >> space on /boot is generally pretty annoying, or worse. > > How huge ?
I'd say that anything above 1TB means that one doesn't care about "wasting" 0.5GB. Tom's Hardware seems to say that even for SSDs the sweet-spot is now at 2TB, so I'd guess that the majority of people with more than 100MB of storage will actually have at least 1TB by now, and many will have 2TB or more. > I do not mind raising the maximal /boot size but it involves > doing a trade-off. With the current proposed 5% priority, which is quite > big, the partition reaches 1GB in 12GB disk space and would reach 1.5GB > in 22GB disk space. This is not huge at all. With 1% priority (the > minimal value with the current algorithm granularity), the partition > would reach 1.5GB in 80GB disk space (still not huge) but would now need > 32GB disk space to reach 1GB instead of 12GB. It would be nice if we could do something where one gets 1GB for systems with tens or hundreds of GB, and have that scale down for tiny disks, and scale up for huge, but we don't currently have a non-linear possibility. BTW Do we really expect to be serving people with tiny disks with our default multi recipe? I'd guess that they'd be more likely to either go for everything on one partition, or configuring things to their exact requirements. I suppose we could have another recipe "multi-partition for tiny disks" that scales things down to lower limits, but we'd probably still want to be able to specify fractions of a percent for the priority for the big-disk version, so that one could use e.g. 0.2% to get to 1.5GB at 750GB disk size. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
signature.asc
Description: PGP signature
