On Saturday, 25 February 2023 08:46:21 CET Bastian Bittorf wrote: > There was an argument by steve: > "waste hundreds of gigabytes on swap space." > > => If a computer has "hundreds of gigabytes" of RAM > (and so swap), you do not care - you have enough resources anyway.
The use-case which was the cause for this change was a system with: - 384 GB RAM ! - 128 GB disk (2x128GB in RAID-1 to be exact) > If you are in a special situation, where you have > more RAM than diskspace, you should better do a manual partitioning, > an not the other way: most people have more diskspace than RAM. The use-case above seem quite unusual to me. Maybe not in professional cloud environments, but I don't have any experience with that. > My usecase (which is broken now) is suspend-to-disk (32 GB RAM, 2TB disc) This is quite a common use case for laptops. Failure to do so can/will result in data loss. FWIW: to save on energy, I'm now also doing that on my PC, which has 64GB RAM which I presume is somewhat large for now. I'm a control freak and an experienced user, so I always do manual partitioning, so I didn't run into this bug. > The change was introduces by: > https://salsa.debian.org/installer-team/partman-auto > > commit 7966fcdbeea345432836c685e425fd59a8628b44 >From that commit: > Template: partman-auto/cap-ram > Type: string > Default: 1024 > Description: for internal use; can be preseeded > > Cap RAM size to specified size in MB, when calculating the swap > partition size. Defaults to 1024, meaning 1GB, and since swap is > maximum 200% of RAM in the default recipes, it results in swap > partitions to be capped at 2GB. To revert to previous behaviour of > uncapped swap size with respect to available ram, preseed this key to > any string, e.g. partman-auto/cap-ram=false So the default was changed to accomodate a system with more RAM (384GB) then disk space (128GB). That amount of RAM is huge and I'd guess quite uncommon and that amount of disk space is quite small. Taking that as default does not make sense to me. Breaking suspend to disk for the majority of users with potential/likely data loss (a browser often uses >2GB), seems ill-advised. Having ppl with more RAM then disk space use preseeding to change the default, seems like a better 'default' and way to deal with that. On Thursday, 8 December 2022 13:05:48 CET Bastian Blank wrote: > On Thu, Dec 08, 2022 at 11:35:43AM +0100, Jan Kowalsky wrote: > > So: please set a default again which is reasonable for laptops and > > workstations. We always recommend debian for desktops to our customers. > > The current default is suitable. Hibernation does not work on any > modern x86 machine and you don't want to have huge swap on desktop > machines as it only adds latency. Hibernation does work on my machine. If you regularly use swap space during normal operation, you just have too little RAM and the appropriate fix is to buy more RAM. But I don't see a/the problem when the use-case is hibernation? So I too think the default behavior should be changed. My 0.02
signature.asc
Description: This is a digitally signed message part.
