From nobody Thu Mar 14 19:39:32 2024 X-Original-To: freebsd-hardware@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 4Twd4Z6WBvz5Dgsj for ; Thu, 14 Mar 2024 19:39:42 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4Twd4Y0VR1z4XHY for ; Thu, 14 Mar 2024 19:39:40 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-doc@fjl.co.uk designates 84.45.41.196 as permitted sender) smtp.mailfrom=freebsd-doc@fjl.co.uk Received: from [127.0.0.1] ([185.69.144.64]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id 42EJdXeQ066920 for ; Thu, 14 Mar 2024 19:39:33 GMT (envelope-from freebsd-doc@fjl.co.uk) Date: Thu, 14 Mar 2024 19:39:32 +0000 From: Frank Leonhardt To: freebsd-hardware@freebsd.org Subject: Re: WD Blue 510 SSD and strange write performance User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <4C9E3F3A-90B3-43B1-B01F-E157E1107E1E@fjl.co.uk> List-Id: General discussion of FreeBSD hardware List-Archive: https://lists.freebsd.org/archives/freebsd-hardware List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hardware@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_SHORT(-0.98)[-0.977]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; NEURAL_HAM_LONG(-0.45)[-0.449]; R_SPF_ALLOW(-0.20)[+ip4:84.45.41.196]; ONCE_RECEIVED(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:25577, ipnet:84.45.0.0/17, country:GB]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hardware@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[fjl.co.uk]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hardware@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4Twd4Y0VR1z4XHY Flash storage is complicated=2E I doubt there's a huge cache in them, as as= it would be volatile it'd be a big no-no for synchronous writes=2E The OS = could cache it, of course=2E And if you're using ZFS then all bets are off= =2E ZFS guarantees (for POSIX) that a synchronous write goes to non volatil= e memory before the system call returns=2E However this does not mean it go= es to the final location on the disk=2E ZFS has an intent log of stuff that= needs to be sorted out sometime, but is safe for now=2E So with can write = away, especially with highly compressible blocks, and it'll go fast enough = until it gets to the point it needs to get the FS in order (you run out of = ZIL)=2E I'm speculating about the cause of the effect in your case, but I'm not su= rprised you're getting an effect=2E Look up Flash storage strategies and the workings of the ZIL for more info= rmation=2E