[EMAIL PROTECTED] wrote on 05/03/2007 11:35:24 AM:
>
> 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.
I think this may be a premature leap -- It is still undetermined if we are
running up against a yet unknown bug in the kernel implementation of gzip
used for this compression type. From my understanding the gzip code has
been reused from an older kernel implementation, it may be possible that
this code has some issues with kernel stuttering when used for zfs
compression that may have not been exposed with its original usage. If it
turns out that it is just a case of high cpu trade-off for buying faster
compression times, then the talk of a tunable may make sense (if it is even
possible given the constraints of the gzip code in kernelspace).
-Wade
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
