I've also noticed brief hangs on my f4k laptop.
build 63 with / on a zfs pool. I was taring up /opt and putting it on a
seperate zfspool.
This second zfspool had compression set to gzip and the machine would
freeze for long periods of time. Setting compression to gzip-9 was
hardest on the machine while setting it to gzip (no compression level
specified) appeared better but still had hangs. I don't have any hard
numbers though but I can provide some if needed.
All the pools are on the one physical laptop harddrive. When I was able
to get some keystrokes in the load was at 18 at one point. Killing the
tar process free'd things up straightaway.
john
Rayson Ho wrote:
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
