From nobody Thu Apr 7 14:02:16 2022 X-Original-To: freebsd-performance@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 42EBC1A956E8; Thu, 7 Apr 2022 14:02:21 +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 4KZ33b5367z4hm4; Thu, 7 Apr 2022 14:02:19 +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 E0F1060C82E; Thu, 7 Apr 2022 16:02:16 +0200 (CEST) List-Id: Performance/tuning List-Archive: https://lists.freebsd.org/archives/freebsd-performance List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-performance@freebsd.org X-BeenThere: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_14f3bd38668fdecfedfad3f860fc22f3" Date: Thu, 07 Apr 2022 16:02:16 +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: <217020e3-0092-b269-96e4-dd77bdcde110@sentex.net> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> <217020e3-0092-b269-96e4-dd77bdcde110@sentex.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ33b5367z4hm4 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]; ARC_NA(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:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; 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 --=_14f3bd38668fdecfedfad3f860fc22f3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Sure!!! good to know mate!!! Thanks Mike!! El 2022-04-07 15:43, mike tancsa escribió: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > On 4/7/2022 7:25 AM, mike tancsa wrote: On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: > Hi Mike! > > Thanks a lot for your comment. I see. As said before, we didn't really enable compression because we just keep the config as FreeBSD leaves by default. Apart from that, having tons of disk space and well... for avoiding the load of compress/decompress... The main reason was it was not enabled by default really and not to have seen a real reason for it.... was not more than that....I appreciate your comments really :) > > 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 You might also want to have a look at this article which I found quite helpful https://klarasystems.com/articles/openzfs1-understanding-transparent-compression/ ---Mike --=_14f3bd38668fdecfedfad3f860fc22f3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Sure!!! good to know mate!!!


Thanks Mike!!

 


El 2022-04-07 15:43, mike tancsa escribió:

= ATENCION
ATENCION
ATENCION= !!! Este correo se ha enviado desde fuer= a de la organizacion. No pinche en los&n= bsp;enlaces ni abra los adjuntos a no se= r que reconozca el remitente y sepa que&= nbsp;el contenido es seguro.

On 4/7/2022 7:25 AM, mike&nbs= p;tancsa wrote:
On 4/7/2022&= nbsp;4:59 AM, egoitz@rama= ttack.net wrote:

Hi Mi= ke!

Thanks a lot for your comment. I see. As said befor= e, we didn't really enable compression because we just keep the config as F= reeBSD leaves by default. Apart from that, having tons of disk space and we= ll... for avoiding the load of compress/decompress... The main reason was i= t was not enabled by default really and not to have seen a real reason for = it.... was not more than that....I appreciate your comments really :)

Think of the&n= bsp;extreme case where you do something like<= /span>

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 I= O on a compressed system. Obviously, as the compress ratio reduces in the r= eal world the benefits become less.  Where that diminishing return is,= not sure.  But something to keep in mind

You might also want to have a look at this article which I found quite help= ful


https://klarasystems.com= /articles/openzfs1-understanding-transparent-compression/
=

    = ---Mike

--=_14f3bd38668fdecfedfad3f860fc22f3--