Re: PR/50638 CVS commit: src/sys/lib/libsa

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR bin/50638; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: PR/50638 CVS commit: src/sys/lib/libsa
Date: Sun, 17 Jan 2016 15:39:36 +0100

 On Sun, Jan 17, 2016 at 11:25:43PM +0900, Izumi Tsutsui wrote:
 > > > > (2) The offered patches fixes the stated original original problem to
 > > > > within a small degree of the cost of uncompression.
 > > > 
 > > > I see no reason to revert it because it isn't default.
 > > > Most ports require "smallest or fastet" and your patch doesn't
 > > > provide either.
 > > 
 > > No, most ports only require small enough and fast enough.
 > 
 > It's your opinion.  On the other hand, martin@ (who have also
 > worked on the same issue for vax etc.) aggreed disabling CRC.
 > Furthermore, CRC values are not checked at all on several ports.
 
 He agreed before the fourth option was available or any hard numbers.
 CRC values are checked if the file is read completely. Whether that
 happens or not depends on a variety of factors, most of them are not
 even MD. That argument has been disproven already.
 
 > If someone really want "small enough and fast enough" method,
 > he/she can introduce another option like LIBSA_CREAD_LIBARCHIVECRC
 > with proper measurements, implementation, and tests, as a test
 > patch martin@ provieded.
 
 I find your attitude to be quite annoying. There is an implementation,
 it is tested and it is even measured. You ignored all that.
 
 > > > Once you can provide real fixes, you can apply it independently.
 > > > Even in that case, "no CRC check" (or zlib version) is still
 > > > faster than yours.
 > > 
 > > If you care so much about fast, why are you compressing in first place?
 > 
 > I (and several Tier II users) have seen the problem for long time
 > and there are several PRs for it, but there is no progress or analysis.
 
 OK, I guess you didn't bother to read the content of this PR at all
 after making up your mind.
 
 > Adding an option is a enough good compromise for me because
 > I (and others) have limited spare time and I don't have any
 > interest in such "best or nothing" strategy which only worked
 > with enough human resources and motivations.
 
 You still haven't answered my question of why seeking is beneficals. You
 pushed your own hack through, completely ignoring the analysis. It has
 been clearly demonstrated that CRC32 is not the majority of the wasted
 time. Removing it (vs just committing the already written patch) does
 not remove fix the problem, it just adds more complications. Your
 behavior is removing any motivation I have for fixing the real problem.
 
 So I am asking you one last time: please revert your hacks.
 
 Joerg