From nobody Thu Apr 07 13:57:33 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 8B1721A931A5; Thu, 7 Apr 2022 13:57:37 +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 4KZ2y807fRz4dhJ; Thu, 7 Apr 2022 13:57:36 +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 F221A60C10A; Thu, 7 Apr 2022 15:57:33 +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="=_49ce93a42b87a5e038a30c28c67e0d83" Date: Thu, 07 Apr 2022 15:57:33 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ2y807fRz4dhJ 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 --=_49ce93a42b87a5e038a30c28c67e0d83 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi!! Thanks ;) really man :) Answering below in bold blue... El 2022-04-07 12:05, Stefan Esser escribió: > I just noticed that this is not the extreme total size of a ZFS pool > (should have noticed this while answering late at night ...) > > And no, a specified life-time of 2880 TB written is not much, it is > at the absolute lower end of currently available SSDs at 360 TB per > 1 TB of capacity. > > YEP THAT'S IT... > > This is equivalent to 360 total capacity writes, but given the high > amount of write amplification that can be assumed to occur in your > use case, I'd heavily over-provision a system with such SSDs ... > (or rather: strictly avoid them in a non-consumer setting). > > It's slightly late for over-provisioning... you know... we have done the zpool create with the whole disk..not just a slice.... > > WE CAN TRY TO BE SLIGHTLY FAR FROM THE 80% CAPACITY LIMIT BUT.... NOT POSSIBLE NOW... AT LEAST FOR THIS GROUP OF SERVERS... > > CHEERS! --=_49ce93a42b87a5e038a30c28c67e0d83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi!!


Thanks ;) really man :)


Answering below in bold blue...

 


El 2022-04-07 12:05, Stefan Esser escribió:

=

I just noticed that this is not the extreme total size of a ZF= S pool
(should have noticed this while answering late at night ...)
And no, a specified life-time of 2880 TB written is not much, i= t is
at the absolute lower end of currently available SSDs at 360 TB = per
1 TB of capacity.
=  
= Yep that's it...
This is equivalent to 360 total capacity writes, but given the h= igh
amount of write amplification that can be assumed to occur in you= r
use case, I'd heavily over-provision a system with such SSDs ... (or rather: strictly avoid them in a non-consumer setting).
=  
= It's slightly late for over-provisioning... you know... we have done the zp= ool create with the whole disk..not just a slice....
=  
= We can try to be slightly far from = the 80% capacity limit but.... not possible now... at least for this group = of servers...
=  
= Cheers!
--=_49ce93a42b87a5e038a30c28c67e0d83--