Bill Sommerfeld wrote:
On Wed, 2009-06-17 at 12:35 +0200, casper@sun.com wrote:
I still use "disk swap" because I have some bad experiences
with ZFS swap. (ZFS appears to cache and that is very wrong)
I'm experimenting with running zfs swap with the primarycache attribute
set to "metadata
On Wed, 2009-06-17 at 12:35 +0200, casper@sun.com wrote:
> I still use "disk swap" because I have some bad experiences
> with ZFS swap. (ZFS appears to cache and that is very wrong)
I'm experimenting with running zfs swap with the primarycache attribute
set to "metadata" instead of the defau
On Thu, 18 Jun 2009, Haudy Kazemi wrote:
for text data, LZJB compression had negligible performance benefits (task
times were unchanged or marginally better) and less storage space was
consumed (1.47:1).
for media data, LZJB compression had negligible performance benefits (task
times were unc
Bob Friesenhahn wrote:
On Wed, 17 Jun 2009, Haudy Kazemi wrote:
usable with very little CPU consumed.
If the system is dedicated to serving files rather than also being
used interactively, it should not matter much what the CPU usage is.
CPU cycles can't be stored for later use. Ultimately,
On Wed, 17 Jun 2009, Haudy Kazemi wrote:
usable with very little CPU consumed.
If the system is dedicated to serving files rather than also being used
interactively, it should not matter much what the CPU usage is. CPU cycles
can't be stored for later use. Ultimately, it (mostly*) does not ma
David Magda wrote:
On Tue, June 16, 2009 15:32, Kyle McDonald wrote:
So the cache saves not only the time to access the disk but also the CPU
time to decompress. Given this, I think it could be a big win.
Unless you're in GIMP working on JPEGs, or doing some kind of MPEG video
editing
Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Rich Teer wrote:
You actually have that backwards. :-) In most cases, compression is
very
desirable. Performance studies have shown that today's CPUs can
compress
data fast
On Wed, June 17, 2009 06:15, Fajar A. Nugraha wrote:
>>> Perhaps compressing /usr could be handy, but why bother enabling
>>> compression if the majority (by volume) of user data won't do
>>> anything but burn CPU?
>
> How do you define "substantial"? My opensolaris snv_111b installation
> has 1.4
On Wed, June 17, 2009 06:03, Kjetil Torgrim Homme wrote:
> I'd be interested to see benchmarks on MySQL/PostgreSQL performance
> with compression enabled. my *guess* would be it isn't beneficial
> since they usually do small reads and writes, and there is little gain
> in reading 4 KiB instead of
"Monish Shah" writes:
>> I'd be interested to see benchmarks on MySQL/PostgreSQL performance
>> with compression enabled. my *guess* would be it isn't beneficial
>> since they usually do small reads and writes, and there is little
>> gain in reading 4 KiB instead of 8 KiB.
>
> OK, now you have s
Unless you're in GIMP working on JPEGs, or doing some kind of MPEG
video editing--or ripping audio (MP3 / AAC / FLAC) stuff. All of
which are probably some of the largest files in most people's
homedirs nowadays.
indeed. I think only programmers will see any substantial benefit
from compression
"Fajar A. Nugraha" writes:
> Kjetil Torgrim Homme wrote:
>> indeed. I think only programmers will see any substantial benefit
>> from compression, since both the code itself and the object files
>> generated are easily compressible.
>
>>> Perhaps compressing /usr could be handy, but why bother e
>On Wed, Jun 17, 2009 at 5:03 PM, Kjetil Torgrim Homme.no> wrote:
>> indeed. =A0I think only programmers will see any substantial benefi=
>t
>> from compression, since both the code itself and the object files
>> generated are easily compressible.
>
>>> Perhaps compressing /usr could be handy, but
On Wed, Jun 17, 2009 at 5:03 PM, Kjetil Torgrim Homme wrote:
> indeed. I think only programmers will see any substantial benefit
> from compression, since both the code itself and the object files
> generated are easily compressible.
>> Perhaps compressing /usr could be handy, but why bother enab
"David Magda" writes:
> On Tue, June 16, 2009 15:32, Kyle McDonald wrote:
>
>> So the cache saves not only the time to access the disk but also
>> the CPU time to decompress. Given this, I think it could be a big
>> win.
>
> Unless you're in GIMP working on JPEGs, or doing some kind of MPEG
> vid
Hello Richard,
Monish Shah wrote:
What about when the compression is performed in dedicated hardware?
Shouldn't compression be on by default in that case? How do I put in an
RFE for that?
Is there a bugs.intel.com? :-)
I may have misled you. I'm not asking for Intel to add hardware
comp
On Tue, June 16, 2009 15:32, Kyle McDonald wrote:
> So the cache saves not only the time to access the disk but also the CPU
> time to decompress. Given this, I think it could be a big win.
Unless you're in GIMP working on JPEGs, or doing some kind of MPEG video
editing--or ripping audio (MP3 / A
Darren J Moffat wrote:
Kyle McDonald wrote:
Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Thommy M. wrote:
In most cases compression is not desireable. It consumes CPU and
results in uneven system performance.
IIRC there was a blog about I/O performance with ZFS stating that
it was
faster
Monish Shah wrote:
Hello,
I would like to add one more point to this.
Everyone seems to agree that compression is useful for reducing load
on the disks and the disagreement is about the impact on CPU
utilization, right?
What about when the compression is performed in dedicated hardware?
Sh
Kyle McDonald wrote:
Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Thommy M. wrote:
In most cases compression is not desireable. It consumes CPU and
results in uneven system performance.
IIRC there was a blog about I/O performance with ZFS stating that it was
faster with compression ON as it
Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Thommy M. wrote:
In most cases compression is not desireable. It consumes CPU and
results in uneven system performance.
IIRC there was a blog about I/O performance with ZFS stating that it was
faster with compression ON as it didn't have to wait fo
On Mon, 15 Jun 2009, Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Rich Teer wrote:
You actually have that backwards. :-) In most cases, compression is very
desirable. Performance studies have shown that today's CPUs can compress
data faster than it takes for the uncompressed data to be read
On Mon, 15 Jun 2009, Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Thommy M. wrote:
In most cases compression is not desireable. It consumes CPU and
results in uneven system performance.
IIRC there was a blog about I/O performance with ZFS stating that it was
faster with compression ON as i
Hello,
I would like to add one more point to this.
Everyone seems to agree that compression is useful for reducing load on the
disks and the disagreement is about the impact on CPU utilization, right?
What about when the compression is performed in dedicated hardware?
Shouldn't compression b
On Mon, 15 Jun 2009, Rich Teer wrote:
You actually have that backwards. :-) In most cases, compression is very
desirable. Performance studies have shown that today's CPUs can compress
data faster than it takes for the uncompressed data to be read or written.
Do you have a reference for such
> On Mon, 15 Jun 2009, dick hoogendijk wrote:
>
>> IF at all, it certainly should not be the DEFAULT.
>> Compression is a choice, nothing more.
>
> I respectfully disagree somewhat. Yes, compression shuould be a
> choice, but I think the default should be for it to be enabled.
I agree that "Comp
On Mon, 15 Jun 2009, Bob Friesenhahn wrote:
> In most cases compression is not desireable. It consumes CPU and results in
> uneven system performance.
You actually have that backwards. :-) In most cases, compression is very
desirable. Performance studies have shown that today's CPUs can compr
On Mon, 15 Jun 2009, Thommy M. wrote:
In most cases compression is not desireable. It consumes CPU and
results in uneven system performance.
IIRC there was a blog about I/O performance with ZFS stating that it was
faster with compression ON as it didn't have to wait for so much data
from the
On Mon, 15 Jun 2009, dick hoogendijk wrote:
> IF at all, it certainly should not be the DEFAULT.
> Compression is a choice, nothing more.
I respectfully disagree somewhat. Yes, compression shuould be a
choice, but I think the default should be for it to be enabled.
--
Rich Teer, SCSA, SCNA, SC
On Mon, 15 Jun 2009 22:51:12 +0200
"Thommy M." wrote:
> IIRC there was a blog about I/O performance with ZFS stating that it
> was faster with compression ON as it didn't have to wait for so much
> data from the disks and that the CPU was fast at unpacking data. But
> sure, it uses more CPU (and
* Shannon Fiume (shannon.fi...@sun.com) wrote:
> Hi,
>
> I just installed 2009.06 and found that compression isn't enabled by
> default when filesystems are created. Does is make sense to have an
> RFE open for this? (I'll open one tonight if need be.) We keep telling
> people to turn on compressi
Bob Friesenhahn wrote:
> On Mon, 15 Jun 2009, Shannon Fiume wrote:
>
>> I just installed 2009.06 and found that compression isn't enabled by
>> default when filesystems are created. Does is make sense to have an
>> RFE open for this? (I'll open one tonight if need be.) We keep telling
>> people to
On Mon, 15 Jun 2009, Shannon Fiume wrote:
I just installed 2009.06 and found that compression isn't enabled by
default when filesystems are created. Does is make sense to have an
RFE open for this? (I'll open one tonight if need be.) We keep
telling people to turn on compression. Are there any
Hi,
I just installed 2009.06 and found that compression isn't enabled by default
when filesystems are created. Does is make sense to have an RFE open for this?
(I'll open one tonight if need be.) We keep telling people to turn on
compression. Are there any situations where turning on compressio
34 matches
Mail list logo
