From nobody Thu Apr 7 11:25:47 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 1DE191A86A2A; Thu, 7 Apr 2022 11:25:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYzb31Xn5z4mwN; Thu, 7 Apr 2022 11:25:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 237BPnGI010096 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Apr 2022 07:25:49 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:434:73cd:9d42:28ad] ([IPv6:2607:f3e0:0:4:434:73cd:9d42:28ad]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 237BPlhB073256 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 7 Apr 2022 07:25:48 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Thu, 7 Apr 2022 07:25:47 -0400 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 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> From: mike tancsa In-Reply-To: <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4KYzb31Xn5z4mwN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-2.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.35)[-0.349]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-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:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received] X-ThisMailContainsUnwantedMimeParts: N 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 :) 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. 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     ---Mike