On Tue, Jul 21, 2020 at 7:36 AM pmkellly(a)frontier.com
<pmkellly(a)frontier.com> wrote:
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.
Yeah, lossy algorithms are common in imaging. There are many kinds
that unquestionably do not produce identical encoding to the original
once decompressed. The algorithms being used by Btrfs are all lossless
compression, and in fact those are also commonly used in imaging: LZO
and ZLIB (ZIP, i.e. deflate) - and in that case you can compress and
decompress images unlimited times and always get back identical RGB
encodings to the original. Short of memory or other hardware error.
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.
I'm not sure what you mean.
Btrfs has always had checksumming from day 0. It was integral to the
design, before the compression algorithms landed. It is to make up for
the fact hardware sometimes lies or gets confused, anywhere in the
storage stack. The default for metadata (the fs itself) and data (file
contents) is crc32c, it is possible to disable it for data but not
possible to disable it for metadata. Compression only ever applies to
data. It's not applied to metadata. Checksumming has intrinsic value
regardless of compression.
--
Chris Murphy