with recent bits ZFS compression is now handled concurrently with
many CPUs working on different records.
So this load will burn more CPUs and acheive it's results
(compression) faster.
So the observed pauses should be consistent with that of a load
generating high system time.
The assumption is that compression now goes faster than when is was
single threaded.
Is this undesirable ? We might seek a way to slow down compression in
order to limit the system load.
-r
Le 3 mai 07 à 14:21, Rayson Ho a écrit :
On 5/3/07, Frank Hofmann <[EMAIL PROTECTED]> wrote:
I'm not quite sure what this test should show ?
I didn't try the test myself... but I think what it shows is a
possible problem that turning compression can hang a machine.
Rayson
Compressing random data is the perfect way to generate heat.
After all, compression working relies on input entropy being low.
But good random generators are characterized by the opposite - output
entropy being high.
Even a good compressor, if operated on a good random generator's
output,
will only end up burning cycles, but not reducing the data size.
Hence, is the request here for the compressor module to 'adapt',
kind of
first-pass check the input data whether it's sufficiently low-
entropy to
warrant a compression attempt ?
If not, then what ?
FrankH.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
