On Sun, 10 Dec 2017 20:37:27 +0100 Antonio Diaz Diaz <[email protected]> wrote:
Hi Antonio, Thanks for the quick response! > > Tests were also performed on the following hardware using 'plzip -vf9 > > foo.tar' with no errors. > > All of them seem to either be 64 bit or have too few processors to reach > the per process memory limit of 32 bit. Am I wrong? I believe you're correct (re: per process limit). The atom n270 is a 32 bit cpu, the other 4 are 64 bit cpus. All are running Slackware 14.2 32 bit. > > Please note that while specifying '-n' & '-s' options are functional > > solutions, they are unacceptable for the intended use case. Regardless > > of a machine's hardware, the resulting compressed files must be > > identical/predictable. > > If you want identical results on 32 and 64 bit machines, I guess you'll > need to limit the number of threads. Limiting the dictionary size may > not be enough on 32 bit systems with many cores. I had assumed (& hoped) plzip would attempt to use as much ram as possible, scale back the number of threads if/when necessary, then throw an error only if there was insufficient memory for a single thread. Please consider this a feature request. :) I've come up with a (hopefully temporary) hack that works on the i7 (& the others). It's essentially what I mentioned above: if an error occurs with '-vf9', loop through '-vf9 -n8' to '-vf9 -n1' until compression succeeds or the last attempt fails. Vriendelijke groeten, Erik -- If you want to improve, be content to be thought foolish and stupid. -- Epictetus _______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
