Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of systemd-swap #173

Open
vilgotf opened this issue Aug 13, 2020 · 5 comments
Open

Future of systemd-swap #173

vilgotf opened this issue Aug 13, 2020 · 5 comments

Comments

@vilgotf
Copy link
Contributor

vilgotf commented Aug 13, 2020

The project is currently not activly developed, but I'll merge pull requests, see third comment

The recent release of systemd-swap 4.4.0 featured a complete rewrite in python. With this release we are nearing a feature complete state so I decided to lists the remaining to-do:s here:

4.3.x (bash version)

  • Bug fixes

>4.4.0

  • Bug fixes and features...

5.0

  • Replace swapFC with swapspace (swapspace is written in C so it either needs to be rewritten or linked with cpython or everything gets rewritten)
  • Support for hibernation (might only support a few bootloaders at first) Hibernation really not possible? #85
  • EOL bash version

5.1

  • Encrypted swap file support

I want to point out that version 5 is a long way of, so if someone is reading this know that pull requests are welcome!

@vilgotf vilgotf pinned this issue Aug 13, 2020
@rjzins
Copy link

rjzins commented May 9, 2021

I just saw that the project seems to be ending. Although systemd/zram-generator should be great for most users, i really like the swapFC functionality you guys have built into this project. Is there any other project you might recommend for dynamic swapfile functionality? Swapspace was the old go-to project, but it was abandoned for sometime. It seems to be alive again. Your roadmap mentions you were going to replace SwapFC with swapspace. Do you think swapspace is better now (after being resurrected)?

@vilgotf
Copy link
Contributor Author

vilgotf commented May 9, 2021

swapFC seems good on the surface but there are some underlying issues with it.

  1. Its filesize is static (this is the selling point of swapspace)
  2. Swap priorities are hard to handle (Linux only allows setting priority >0 so reducing the priority by one on every new swapfile will eventually lead to negative priority and log spam, see Sorry, swap priorities smaller than -1 may only be assigned by the kernel itself #135)
  3. The current implementation runs a loop, checking swap usage every second which is redundant (although this is a nitpick and it's not like this causes huge cpu usage)

I've not personally used swapspace, just checked the description and the code, but I'd say use that.

@vilgotf
Copy link
Contributor Author

vilgotf commented May 9, 2021

The main reason for me stopping development on systemd-swap is I just don't see the need for systemd-swap. zram & zswap should be configured with kernel parameters, /etc/tmpfiles.d or zram-generator. The only real interessting thing with systemd-swap has (imo) always been swapFC, but since swapspace seems to do everything swapFC does but better I don't really see a future for it.

I'd have no problem working on an alternative to swapspace / fork / contribute if somebody's use case isn't fulfilled by it (if so comment) but since I personally just use zram (and recommend most ppl to just use that) I've got no motivation to do that right now.

@Zeioth
Copy link

Zeioth commented Sep 22, 2021

I literally use it for swapFC. It make the system really robust. Even if you have a memory leak, the PC won't freeze, and you have time to notice.

@oold
Copy link
Collaborator

oold commented May 2, 2024

I have been wondering about whether archiving this repo would be the best course of action. None of us really want to work on it anytime soon and I'd like to prevent people from picking this up and running into issues nobody is going to triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants