From nobody Thu Apr 07 08:59:50 2022 X-Original-To: freebsd-fs@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 901611A80E64; Thu, 7 Apr 2022 08:59:53 +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 4KYwLc4b9Kz3pb3; Thu, 7 Apr 2022 08:59:52 +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 A23F660C6A9; Thu, 7 Apr 2022 10:59:50 +0200 (CEST) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c2807b764a57b09883b960b84ffbc8e7" Date: Thu, 07 Apr 2022 10:59:50 +0200 From: egoitz@ramattack.net To: mike tancsa Cc: Bob Friesenhahn , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}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> Message-ID: <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYwLc4b9Kz3pb3 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)[]; RCVD_TLS_LAST(0.00)[]; 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]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; 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 --=_c2807b764a57b09883b960b84ffbc8e7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 :) Cheers, El 2022-04-06 22: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/6/2022 4:18 PM, Bob Friesenhahn wrote: On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: > WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... There seems to be a problem with your caps-lock key. Since it seems that you said that you are using maildir for your mail server, it is likely very useful if you do enable even rather mild compression (e.g. lz4) since this will reduce the write work-load and even short files will be stored more efficiently. FYI, a couple of our big zfs mailspools sees a 1.24x and 1.23x compress ratio with lz4. We use Maildir format as well. They are not RELENG_13 so not sure how zstd would fair. ---Mike --=_c2807b764a57b09883b960b84ffbc8e7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Mike!


Thanks a lot for your comment. I see. As said before, we didn't really e= nable compression because we just keep the config as FreeBSD leaves by defa= ult. Apart from that, having tons of disk space and well... for avoiding th= e 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 t= han that....


I appreciate your comments really :)


Cheers,

 


El 2022-04-06 22: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/6/2022 4:18 PM, Bob = ;Friesenhahn wrote:
On Wed, = ;6 Apr 2022, egoitz@= ramattack.net wrote:

WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEF= AULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID= HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER D= ISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU C= OSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION....

There seems to b= e a problem with your caps-lock key.
Since it seems that you said that you are using maildir for you= r mail server, it is likely very useful if you do enable even rather mild c= ompression (e.g. lz4) since this will reduce the write work-load and even s= hort files will be stored more efficiently.
FYI, a couple of our big zfs  mailspools sees a 1.24x and 1.23x compre= ss ratio with lz4.  We use Maildir format as well.  They are not = RELENG_13 so not sure how zstd would fair.

    ---Mike

--=_c2807b764a57b09883b960b84ffbc8e7--