On 7/20/20 13:31, Samuel Sieb wrote:
First a bit of background all the PCs (Fedora WS) I maintain are
bought with lots of ram 8GB is the min. I don't think I've ever seen
swap move off zero and no one has reported any sort of slowdowns. Yet
we do lots of memory intensive things. Of course all this is with ext4.
That is surprising. Usually at least something ends up in the swap.
I'm a convert from that proprietary "we know what's best for you" OS.
One of the major things that annoyed me about it was that it horded all
the RAM and Swapped everything. One day while talking with a colleague
he suggested that I should switch to Linux and he recommended Fedora. I
got a copy of Fedora 16 WS and loaded it. That fact that swapping was
non-existent and Fedora didn't hord the RAM was one of the things that
helped me decide to switch everything here to Fedora.
On these machines Disks says that swap lives at
/dev/fedora_localhost-live/swap00 and showns no usage. Monitor shows 0
bytes used for swap. I've never seen these move off zero. I haven't
changed any of the disk parameters. They are all at their default values
as installed.
Careful what you're using to measure with. The only accurate
measurement is "zramctl". That will tell you exactly how much RAM > the zram device is using.
Thanks
You really need to read more about zram. There is no dedicated space
for it. It only uses RAM as swap is needed. And it uses less RAM than
the pages that are getting swapped out, so there's a net reduction in
RAM usage without hitting the disk.
cmurf explained that to me yesterday, but thanks.
These compression algorithms have been tested very hard and are used
everywhere. I've never seen mention of any corruption issues.
I must say that all of my compression experience has been with the
algorithms used to compress images. I won't bore you with the details
but we wrote software to build various image files with certain
characteristics in pristine form. We did not use the standard test
images that are sometimes used. The test files we used were structured
to see how good a job the algorithms could do preserving data. Then we
saved and opened them using the various standardized algorithms used for
the associated file types and analyzed the results. The results were not
impressive. We concluded that the results were fine for images. If some
pixel values change, the average user will not notice it; so it's not
critical. However there are many other kinds of data where such changes
would be critical. Now I know the algorithms used for images are
different from those used for general file compression on disk, but
still, I try to minimize risk. Since I'm never short of disk space I
prefer not to use compression. I was very excited and pleased when I
found out that btrfs check-sums files. However now I understand that it
is a patch to make up for the compression. It seems like a zero sum gain
to me.
If you really want to disable zram (there's no reason to), I believe the
simplest method is "touch /etc/systemd/zram-generator.conf".
And it's nothing to do with btrfs.
Yes. I understand now that zram is not part of btrfs. It's just that it
showed up with btrfs and was yet another thing that raised lot of
questions. Now that I understand how zram works, I won't be shutting it
off. I do want to have a swap space, and though it doesn't seem to get
used, I want it just in case...
Thanks and Have a Great Day!
Pat (tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/test@xxxxxxxxxxxxxxxxxxxxxxx
