From nobody Wed Apr 6 21:19:22 2022 X-Original-To: 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 DA72D1A9F4B2 for ; Wed, 6 Apr 2022 21:19:33 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (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 4KYcpX42LGz4pkd for ; Wed, 6 Apr 2022 21:19:32 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from [IPV6:2001:16b8:6410:e900:8468:f98d:8c6b:de2c] (200116b86410e9008468f98d8c6bde2c.dip.versatel-1u1.de [IPv6:2001:16b8:6410:e900:8468:f98d:8c6b:de2c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 564CB2492C for ; Wed, 6 Apr 2022 21:19:23 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------G4wltCyoa74m5jS4qYaJ2Oo0" Message-ID: Date: Wed, 6 Apr 2022 23:19:22 +0200 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: performance@freebsd.org References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> From: Jan Bramkamp In-Reply-To: X-Rspamd-Queue-Id: 4KYcpX42LGz4pkd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-3.26 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[performance@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_HAM_SHORT(-0.96)[-0.963]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[2001:16b8:6410:e900:8468:f98d:8c6b:de2c:received] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------G4wltCyoa74m5jS4qYaJ2Oo0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06.04.22 22:43, mike tancsa wrote: > 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. I've found that Dovecot's mdbox format compresses a lot better than Maildir (or sdbox), because it stores multiple messages per file resulting in files large enough to contain enough exploitable reduncancy to compress down to the next smaller blocksize. In a corporate or education environment where users tend to send the same medium to large attachments multiple times to multiple recipients on the same server Dovecot's single instance storage is a game changer. It reduced my IMAP storage requirements by a *factor* of 4.7 which allowed me to get rid of spinning disks for the mail servers instead of playing losing games with hybrid storage. Dovecot also supports zlib compression in the application instead of punting it to the file system. I don't know if Cyrus IMAP offers similar features, but if it does I would recommend evaluating them instead of compressing or deduplicating at the file system level. --------------G4wltCyoa74m5jS4qYaJ2Oo0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06.04.22 22:43, mike tancsa wrote:
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.
I've found that Dovecot's mdbox format compresses a lot better than Maildir (or sdbox), because it stores multiple messages per file resulting in files large enough to contain enough exploitable reduncancy to compress down to the next smaller blocksize. In a corporate or education environment where users tend to send the same medium to large attachments multiple times to multiple recipients on the same server Dovecot's single instance storage is a game changer. It reduced my IMAP storage requirements by a factor of 4.7 which allowed me to get rid of spinning disks for the mail servers instead of playing losing games with hybrid storage. Dovecot also supports zlib compression in the application instead of punting it to the file system. I don't know if Cyrus IMAP offers similar features, but if it does I would recommend evaluating them instead of compressing or deduplicating at the file system level.
--------------G4wltCyoa74m5jS4qYaJ2Oo0--