Hi, thank you for all the testing and comparisons between different approaches. It looks really interesting.
> The ideal scenario is to get everyone on the same page, and so far it > looks like systemd's zram-generator, built in Rust, meets all the > requirements. That needs to be confirmed, but also right now there's a > small problem, it's not working. So we kinda need a someone familiar > with Rust and systemd to take this on, if we want to use the same > thing everywhere. > https://github.com/systemd/zram-generator/issues/4 For a while, the only feedback I had for zram-generator was from people interested in rust. It's great that somebody is giving it a go ;) I think the report in that issue is a slight exaggeration — IIUC, this failure only occurs if zram-generator.conf is created and systemctl daemon-reload and systemctl start swap.target called on a running system. After reboot, things would still work. Obviously, it would be better to handle this case too. I pushed some commits to the master branch now that close all the four open issues, and this case should be handled too now. If anything is wrong, please report it here or in bugzilla. I'll tag a new version with those changes in a few days if nothing else pops up. Zbyszek PS. I had a really surprising failure mode: on a VM with 2GB RAM (as shown by free), the genarator was doing nothing and simply exiting with no error. It turns out that the machine had "maximum allocation" bigger than "current allocation", and for a brief momment during boot /proc/meminfo would report more memory. Took me a while to figure this one out. Zbyszek _______________________________________________ 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
