From nobody Thu Apr 07 14:01:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F299B1A9499D; Thu, 7 Apr 2022 14:01:07 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ32B4GXpz4gtl; Thu, 7 Apr 2022 14:01:06 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id A4C8160C00B; Thu, 7 Apr 2022 16:01:04 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_74b7e4b05962e4b9793f3fbab21fa2c0" Date: Thu, 07 Apr 2022 16:01:04 +0200 From: egoitz@ramattack.net To: mike tancsa Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> Message-ID: <1c114208ae8387fc7c4291d1cc66227e@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ32B4GXpz4gtl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_74b7e4b05962e4b9793f3fbab21fa2c0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Mike! Thanks a lot for your answer :) :) and your time :) :) Answering below in blue bold... El 2022-04-07 13:25, mike tancsa escribió: > On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: > >> > Hi, > > With respect to compression, I think there is a sweet spot somewhere, where compression makes things faster if your disk IO is the limiting factor and you have spare CPU capacity. I have a separate 13.x zfs server with ztsd enabled and I get compression rations of 15:1 as it stores a lot of giant JSON txt files. > > ZTSD OR ZTSD-2 AS IN SOME MAIL PREVIOUS STEFAN STATED?. I ASSUME ARE NOT THE SAME... ARE THEY?. > > Think of the extreme case where you do something like > > dd if=/dev/zero of=/tank/junk.bin bs=1m count=10000 > > as this is a 20G file that takes just a few hundred bytes of write IO on a compressed system. Obviously, as the compress ratio reduces in the real world the benefits become less. Where that diminishing return is, not sure. But something to keep in mind > > TOTALLY TRUE AND TOTALLY AGREE MIKE!! > CHEERS!! --=_74b7e4b05962e4b9793f3fbab21fa2c0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Mike!


Thanks a lot for your answer :) :) and your time :) :)


Answering below in blue bold...

 


El 2022-04-07 13:25, mike tancsa escribió:

=
On 4/7/2022 4:59 = ;AM, egoitz@ramattack.net&= nbsp;wrote:

Hi,

  &n= bsp; With respect to compression, I think there is a sweet spot somewhere, = where compression makes things faster if your disk IO is the limiting facto= r and you have spare CPU capacity.  I have a separate 13.x zfs server = with ztsd enabled and I get compression rations of 15:1 as it stores a lot = of giant JSON txt files.
=  
= ztsd or ztsd-2 as in some mail prev= ious Stefan stated?. I assume are not the same... are they?.

Think of the&= nbsp;extreme case where you do something like=

dd if=3D/dev= /zero of=3D/tank/junk.bin bs=3D1m count=3D10000
=  
= as this is a 20G file that takes just a few hundred bytes of write IO on a = compressed system. Obviously, as the compress ratio reduces in the real wor= ld the benefits become less.  Where that diminishing return is, not su= re.  But something to keep in mind
=  
= Totally true and totally agree Mike= !!
=  
Cheers!! --=_74b7e4b05962e4b9793f3fbab21fa2c0--