From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E5840158042 for ; Sat, 16 Nov 2024 11:02:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3170BE089F; Sat, 16 Nov 2024 11:02:47 +0000 (UTC) Received: from poodle.tulip.relay.mailchannels.net (poodle.tulip.relay.mailchannels.net [23.83.218.249]) (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) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A60A6E0891 for ; Sat, 16 Nov 2024 11:02:46 +0000 (UTC) X-Sender-Id: thundermail|x-authsender|confabulate@kintzios.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1DC857831CD for ; Sat, 16 Nov 2024 11:02:45 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1731754964; a=rsa-sha256; cv=none; b=smULkfJeVm4QT9ifZMzeKmJoWPtE8Mp8oeGbTmMjN5A5C9/g1sZmJrJw5LPANxcKnItDAy Bs6wugZUjjMr0NyCVk7147QrLpIkgtpLhu+4RfrwY/WiccM0v8EdLiQzWBZMBZH1a+hKE4 KLMJD5E2WRV+gZnc0Mu0CjaMaQcAVM7klwt10sWWp0Q/Bp8RnPyYDx3iKHJi/TX3D+RY0m Du1UyThstKkHJJbFu4JnCXy3dLQR1pZvVnFQMC9A2RPMnmw9HRN6PYZfhYfGxvTWrLKj4S /DV8OLhBubIHytZgBR81ik4wEju7erFu/OXR++FlXYFpSPxiE/FhOuufDVgjKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1731754964; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=MYSpiVruY08hYmD0vXJXb6mO8P8aZD8n5cowSdRDi1w=; b=UfUgyO6bP9wUZt8yaMzvUWwDoYBBh3Ld3ejxHsrYq7byhqOhbfOMhi+cNC9jUK5rR8mLir QPFa/9A3dxaZy+9s5/Iw6YXRm37yj3aNs+OPLcFzRL1EyKWfuTVr5ng8bq5c2AHuci1BRb 9gcPLYZYN++/tX1qgUu74/yBSoAynK/Q/RytEYqTzNXtA5Av/EVVddiXk7XtcUY7VZSy+I BT38DpPJUGyQphFMgnqu4j6wttWR9XKtblfqSSXfgsbqLI7jIKF1GmRnopfFoHfrv4NdwJ G6WRSyzBFCeV526t1XLckVr2RQ0+iG7Dlg3LVmI9lggQ17uIDIApgtUvcMMHiA== ARC-Authentication-Results: i=1; rspamd-7456989c76-jhv95; auth=pass smtp.auth=thundermail smtp.mailfrom=confabulate@kintzios.com X-Sender-Id: thundermail|x-authsender|confabulate@kintzios.com X-MC-Relay: Neutral X-MailChannels-SenderId: thundermail|x-authsender|confabulate@kintzios.com X-MailChannels-Auth-Id: thundermail X-Share-Bottle: 2e3096866979a5ca_1731754964738_3209235963 X-MC-Loop-Signature: 1731754964738:4280417150 X-MC-Ingress-Time: 1731754964737 Received: from mailclean11.thundermail.uk (mailclean11.thundermail.uk [149.255.60.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.138.111 (trex/7.0.2); Sat, 16 Nov 2024 11:02:44 +0000 Received: from cloud238.thundercloud.uk (cloud238.thundercloud.uk [149.255.62.116]) by mailclean11.thundermail.uk (Postfix) with ESMTPS id 5368E1E0002 for ; Sat, 16 Nov 2024 11:02:42 +0000 (GMT) Authentication-Results: cloud238.thundercloud.uk; spf=pass (sender IP is 217.169.3.230) smtp.mailfrom=confabulate@kintzios.com smtp.helo=rogueboard.localnet Received-SPF: pass (cloud238.thundercloud.uk: connection is authenticated) From: Michael To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Seagate hard drives with dual actuators. Date: Sat, 16 Nov 2024 11:02:25 +0000 Message-ID: <2633393.Lt9SDvczpP@rogueboard> In-Reply-To: References: <115451235.nniJfEyVGO@rogueboard> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4389730.ejJDZkT8p0"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-PPP-Message-ID: <173175496177.3042606.6556953008235318657@cloud238.thundercloud.uk> X-PPP-Vhost: kintzios.com X-Spamd-Result: default: False [-1.51 / 999.00]; SIGNED_PGP(-2.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_ALLOW(0.00)[kintzios.com,none]; FROM_HAS_DN(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; REPLYTO_DOM_NEQ_TO_DOM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:34931, ipnet:149.255.60.0/22, country:GB]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[gentoo-user@lists.gentoo.org]; R_DKIM_NA(0.00)[]; NEURAL_HAM(-0.00)[-0.999]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; HAS_REPLYTO(0.00)[confabulate@kintzios.com] X-Rspamd-Queue-Id: 5368E1E0002 X-Rspamd-Action: no action X-Rspamd-Server: mailclean11 X-Archives-Salt: 5674ea1e-5dbd-4f5a-b474-705fa85db045 X-Archives-Hash: 78e0f7816d75d01bd995105938eec306 --nextPart4389730.ejJDZkT8p0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Michael To: gentoo-user@lists.gentoo.org Reply-To: confabulate@kintzios.com Subject: Re: [gentoo-user] Seagate hard drives with dual actuators. Date: Sat, 16 Nov 2024 11:02:25 +0000 Message-ID: <2633393.Lt9SDvczpP@rogueboard> MIME-Version: 1.0 On Friday 15 November 2024 22:13:27 GMT Rich Freeman wrote: > On Fri, Nov 15, 2024 at 10:35=E2=80=AFAM Michael wrote: > > Host managed SMRs (HM-SMR) require the OS and FS to be aware of the need > > for sequential writes and manage submitted data sympathetically to this > > limitation of the SMR drive, by queuing up random writes in batches and > > submitting these as a sequential stream. > >=20 > > I understand the ext4-lazy option and some patches on btrfs have improv= ed > > performance of these filesystems on SMR drivers, but perhaps f2fs will > > perform better? :-/ >=20 > IMO a host-managed solution is likely to be the only thing that will > work reliably. =20 I think HM-SMRs may be used in commercial applications and DM-SMRs fed to t= he=20 unaware retail consumer, not that we can tell without the OEMs providing th= is=20 rather vital piece of information. I assume (simplistically) with DM-SMRs = the=20 discard-garbage collection is managed wholly by the onboard drive controlle= r,=20 while with HM-SMRs the OS will signal the drive to start trimming when the= =20 workload is low in order to distribute the timing overheads to the system's= =20 idle time. > If the drive supports discard/trim MAYBE a dumber > drive might be able to be used with the right filesystem. Even if > you're doing "write-once" workloads any kind of metadata change is > going to cause random writes unless the filesystem was designed for > SMR. Ideally you'd store metadata on a non-SMR device, though it > isn't strictly necessary with a log-based approach. I've considered the flash storage trim operation to be loosely like the SMR= =20 behaviour of read-modify-write and similarly susceptible to write- amplification, but with SSD the write speed is so much faster it doesn't ca= use=20 the same noticeable slowdown as with SMR. =20 > If the SMR drive tries really hard to not look like an SMR drive and > doesn't support discard/trim then even an SMR-aware solution probably > won't be able to use it effectively. The drive is going to keep doing > read-before-write cycles to preserve data even if there is nothing > useful to preserve. >=20 > -- > Rich Sure, trimming nudges by the OS won't have an effect on the DM-SMR drive si= nce=20 small changes to shingled bands are managed internally by the onboard STL=20 controller and the persistent SMR cache. However, there are some things a= =20 filesystem driver can still provide to improve performance. For example,=20 compression, caching-batching to facilitate sequential writing directly in= =20 whole bands rather than random small regions within a band, etc. In the ca= se=20 of ext4 'lazy writeback journaling' the allocated journaling space is=20 increased upfront and the metadata are written once only with a mapping=20 inserted in memory to join the location of the metadata in the journal itse= lf=20 instead of writing it twice. The two links at the bottom of this page expl= ain=20 it better: https://www.usenix.org/conference/fast17/technical-sessions/presentation/ aghayev I'm not sure if this happens automatically, or if some mkfs and mount=20 option(s) need to be called upon. With up to 30x faster write speed, perha= ps=20 this is something Dale may want to investigate and experiment with. --nextPart4389730.ejJDZkT8p0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmc4e8EACgkQseqq9sKV ZxlYhhAAnitNejCtJX1ARqr4mOEdCoOHQ0Wk674IOnkaKyN3AfB7bg2PzeBOiVar en0FxR8O0v451Sj3hpmi+t0as9WPT06bRwzo0Gx8TRKRQ9JJNxIzs6AscDlwDVH8 9S1U8zhB3y4jRxBZwBAsjE+LSo5+sUU1/jiuXlKN+K/HlsGvBmrOe4Hb8IUDr4B+ YAYnDsPAbyOnVYctFnsgieBhpLyB1sTk4VAQTycPhaHxWgwwDj+A7Bd6GA58F9dX Q28HDSBOwY304u4giUmZtxOxlIfyTpSVKbYQoqUwPKXOQ0OjlueePQSMtYV6NGNO nhQ63WMdQoIWO7anybigtbI+nKTd3E/OBxAt32hF4mgb0N/c+SxBVcPPQZU4R5Jb nE4MyVA7kLoqserxMXgW9DXW4/7XeGidh68EMg48w82vhs2x7RzCOyju2gyZFzZh bB/W35VHMDscYwBcSYZaAOU7dD+cmyYFZr6nG+R0QRj/x7qn5ePIPLzaWy6ilbQs suO+3nh3wJKt1W7nxRoSHEawpyhj+HVpYEIX8hsRIo57i8QdQQku+x+sjTF6yNdo A1RiIb85HoKodG95+gooDBt2c0ewpazBFDvRdBQNcieTPAcr6dwofKz+4JQaef4x /22ghSwxtNT3O1d/r55gjvCJFXOBWxBjn2Euz8wPR61cALXVD/A= =mxHr -----END PGP SIGNATURE----- --nextPart4389730.ejJDZkT8p0--