On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy <li...@colorremedies.com> wrote:
> D. Which directories? Some may be outside of the installer's scope. > > /usr > /var/lib/flatpak > ~/.local/share/flatpak > I have a concern regarding games. Currently, we have a few a bit more demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In the glorious future (tm) we might get more. Games are very sensitive to available CPU cycles and context switching and usually come with their data files already compressed. Including the btrfs compression by default on flatpak dirs could lead to lowered performance whenever the game tries to load some assets (older titles do that during the loading screen, newer titles stream new assets constantly during gameplay and any slowdown manifests as game stuttering). May it make sense to have different compression defaults per Edition/Spin? For example, Workstation is likely used on computers which have sufficient disk space, don't suffer from disk wear out that much (compared to SD cards), and users are likely to play games on them. On the other hand, ARM or IoT devices are the very opposite and compression can be very useful there. > /var/lib/containers/ > ~/.local/share/containers/ > ~/.var > If we enable it on ~/.var, it will affect all Steam games installed through the Steam flatpak. So any AAA games you play including those emulated through Proton will need to deal with extra compression. I find it unlikely that the user experience would be unchanged. It would be similar to Microsoft enabling disk compression on Program Files by default. I actually tried to figure out which locations are compressed by default on Windows 10, and I failed in searching, but I looked at my Win10 instance and I didn't find any folders that would have compression enabled. > ~/.cache > > (Plausible this list should be reversed. While compressing ~/.cache > may not save much space, it's likely hammered with more changes than > other locations, hence more benefit in terms of reducing write > amplification.) > I'm personally more concerned about reduced performance in e.g. my web browser than disk wear out. I don't see much harm in compressing /usr, because it's a read-only location that gets loaded once when the app starts (it might delay the app startup a bit, though, and decrease the perceived snappiness of the desktop). But I'm concerned about compressing locations which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5 years and I'm just at 10% of expected TBW (total bytes written). If the SSD lasts 50 or 100 years is not really important for me, but the desktop and app responsiveness is (and game performance, of course:)). I think write amplification is a problem specific to devices with SD cards, and for anyone else, it might be better to leave it unset and let people enable it (it's simple) if they want it for their use case.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
