Fedora Workstation 33 Aiming To Have SWAP-On-ZRAM By Default

[starshipeleven]

As for UNIX philosophy, files should be files and store on filesystems. If there were problems for the kernel storing swap on these files, the solutions should have ended up in kernel, rather than a hack on the FS level. storing swap files on disk, then . I think the solution to the problem should have fixed in the kernel swap module, rather than tweaks and work around on FS layer.

To be fully 100% fair, swap files are also hacks to the FS layer as they are special files handled in a special way by the filesystem, and you can use them safely only on filesystems that support this feature (i.e. have the relevant hacks in place to suspend any filesystem logic from touching this "file").
For example btrfs only recently added support for that, and making a swap file on ZFS is not a good idea at all (it has its own way to make a swap device that does not involve swap files, as described above).

But it's imho acceptable as the filesystem is just moving out of the way and relinquishing control over some disk memory areas to the kernel, and not doing its thing under the kernel's nose.

[starshipeleven]

ZFS compressing files?

Who is talking of ZFS compressing files? Don't offend my intelligence you peasant.

ZFS has no concept of "swap file" at all so if I'm saying its handling of compressing swap is wrong this has NOTHING to do with transparent file compression support.

ZFS does a custom shenanigan with a zpool to offer a swap device that is stored on a filesystem and is compressed by the filesystem logic under the kernel's nose. That's what I disagree with.

I don't need 25 tools. I have ZFS. It does one thing and does it well. It manages my data. That's UNIX philosophy.

More offending of my intelligence by strawmanning.

I specifically mentioned the fact that it also can generate NFS sand SMB shares, and you go on a tangent about compression and encryption.

[S.Pam]

Not an issue for any consumer SSD produced from 2014 onwards. Another reason why compressed swap has never gone anywhere I guess.

Terrabtes written is indeed a KPI that your warranty specifies.
Look at Write Endurance table at https://www.anandtech.com/show/13761...lus-ssd-review

600 TB | 0.3 DWPD

[S.Pam]

I am not too familiar with ZFS as I use mostly Btrfs these days. But this seems interesting. Https://www.joyent.com/blog/bruning-...fs-record-size My take on that is that with some tuning, this could indeed lead to some expected performance increase. Would be nice to do verify this somehow.

As for UNIX philosophy, files should be files and store on filesystems. If there were problems for the kernel storing swap on these files, the solutions should have ended up in kernel, rather than a hack on the FS level. storing swap files on disk, then . I think the solution to the problem should have fixed in the kernel swap module, rather than tweaks and work around on FS layer.

[starshipeleven]

First of all, not always easy to add more RAM.

It's been easy enough that most projects like zram zswap and so on are basically on life support, and people can work around the utter bullshit swapping logic in the kernel that freezes the system by just not having a swap file at all.

That aside, your point about SSDs is not relevant either. compression outperforms read/write rates of even very fast SSDs.

My point is valid because even adding compression the RAM vs SSD speed difference is still the same order of magnitude. It is better on paper but in practice it does not matter that much.

reduce bytes written on the SSD which increases its life span.

Not an issue for any consumer SSD produced from 2014 onwards. Another reason why compressed swap has never gone anywhere I guess.

[skeevy420]

Yes it is like that for every filesystem that supports swap files.
The swap file is allocated as contiguous and it is a "special file". Any filesystem logic ignores that area from that moment onwards, all writing and reading to it is done by kernel directly, by physical address.

I'm personally against using a filesystem to compress swap as it adds a layer of stuff that does not make sense for swap, and will slow down the job. Any compression should happen at the kernel level (which is the one actually reading and writing to disk) while the swap file remains this special file thing.

The fact that ZFS can do shenanigans like that is one of the things I don't like about it, it tries to do stuff that isn't its job, if the kernel sucks and can't compress swap, if there is no decent tool to make smb or NFS shares and whatnot, your friggin filesystem (and tools) should NOT take over and do that.

Among other things it is a violation of Unix principles, but of course that's a thing that is only read very wrong for the sake of bashing systemd, but I digress.

That said, I have the strong suspicion that swap and "lack of RAM" issues in general have been mostly ignored in the last decade because you could easily "fix" them by adding more RAM on PC/Servers, or keep using ancient 2.6 kernels (for embedded devices where RAM footprint is significant).

I also personally think compressed swap isn't particularly relevant in this day and age where 512GB SSDs are getting cheap. I would like a lot a solution for the DoS issue that swapping and low RAM causes (i.e. lockup), but that's another story.

ZFS compressing files? That's a matter of interpretation of that "do one thing and do it well" rule. ZFS does do one thing well -- managing data. If they need to be compressed, encrypted, or require special needs like atime or case insensitivity, ZFS handles it and handles it well.

Need /usr/share/* using gzip9 to save space? Then I can create a dataset for /usr/share and set gzip9 for it.
Need /home/username encrypted? Then create a /home/username dataset with encryption.
Need to save space with minimal performance hit? Then create a dataset with LZ4 compression (or Zstd-fast sometime soon)
Need to install mods for a Windows game and Linux case sensitivity is messing with you? Well, you know the answer.

I don't need 25 tools. I have ZFS. It does one thing and does it well. It manages my data. That's UNIX philosophy.

[skeevy420]

What do you mean? Z3fold is also the same. Does not compress on-disk.

That it's great for zswap. That's why I kept in-ram bolded.

Add this to your kernel command line:

zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=20 zswap.zpool=z3fold

Tweak the max_pool_percent as necessary

[S.Pam]

That said, I have the strong suspicion that swap and "lack of RAM" issues in general have been mostly ignored in the last decade because you could easily "fix" them by adding more RAM on PC/Servers, or keep using ancient 2.6 kernels (for embedded devices where RAM footprint is significant).

I also personally think compressed swap isn't particularly relevant in this day and age where 512GB SSDs are getting cheap. I would like a lot a solution for the DoS issue that swapping and low RAM causes (i.e. lockup), but that's another story.

First of all, not always easy to add more RAM. That aside, your point about SSDs is not relevant either. compression outperforms read/write rates of even very fast SSDs. Compression would not only reduce the user waiting for swap, but also reduce bytes written on the SSD which increases its life span.

[starshipeleven]

Unfortunately compressed swap files are not supported. I guess the swap file actually just acts as a place holder for the physical address the swap writes to.

Yes it is like that for every filesystem that supports swap files.
The swap file is allocated as contiguous and it is a "special file". Any filesystem logic ignores that area from that moment onwards, all writing and reading to it is done by kernel directly, by physical address.

I'm personally against using a filesystem to compress swap as it adds a layer of stuff that does not make sense for swap, and will slow down the job. Any compression should happen at the kernel level (which is the one actually reading and writing to disk) while the swap file remains this special file thing.

The fact that ZFS can do shenanigans like that is one of the things I don't like about it, it tries to do stuff that isn't its job, if the kernel sucks and can't compress swap, if there is no decent tool to make smb or NFS shares and whatnot, your friggin filesystem (and tools) should NOT take over and do that.

Among other things it is a violation of Unix principles, but of course that's a thing that is only read very wrong for the sake of bashing systemd, but I digress.

That said, I have the strong suspicion that swap and "lack of RAM" issues in general have been mostly ignored in the last decade because you could easily "fix" them by adding more RAM on PC/Servers, or keep using ancient 2.6 kernels (for embedded devices where RAM footprint is significant).

I also personally think compressed swap isn't particularly relevant in this day and age where 512GB SSDs are getting cheap. I would like a lot a solution for the DoS issue that swapping and low RAM causes (i.e. lockup), but that's another story.

[S.Pam]

zstd+z3fold

What do you mean? Z3fold is also the same. Does not compress on-disk.