From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-205042-garchives=archives.gentoo.org@lists.gentoo.org>
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 70F7E158042
for <garchives@archives.gentoo.org>; Sat, 16 Nov 2024 20:13:51 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9989CE092E;
Sat, 16 Nov 2024 20:13:45 +0000 (UTC)
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181])
(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 164BBE0918
for <gentoo-user@lists.gentoo.org>; Sat, 16 Nov 2024 20:13:44 +0000 (UTC)
Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-3a7372070f9so8810745ab.0
for <gentoo-user@lists.gentoo.org>; Sat, 16 Nov 2024 12:13:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1731788022; x=1732392822;
h=content-transfer-encoding:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=yQ6IvlCeWNxY49CHVcnUY5+KHZvpLhpC2Xm/Y8wqC8g=;
b=OpdinoLUfTLZ2k4atJ2WpQ6nCuuBt8iLXZ5Qs+iLTjtZREgl41h5RBogFNxuEKB6d1
IDqsHs6Erjy8vWDJTOFhedb6lAvykfljiLvlFvf2yHE4pUIq/KR3zBEUcEoRqwg7nUoH
85p13AlK6edotvQuzbYBH1swVsrRQG6NbYXMJC6RltOEbIQtw9np/jp8tKvJJln4c4ci
9h1nF27K3gd6YGxm49T7VXgMZa7hMyz1tZBLf17pP4jsgIEGugIWu/lFns3wMqj6henu
F6sU63MkQ+AmHLCz2+jXUoWBZxwnq2z9gncDuv+CLnikYgYr+Aa2KVJUXCknPuK8U8Wx
Kw/A==
X-Gm-Message-State: AOJu0YyGpD7UGbyqfiFq+NjiLETODyq1p5CgvsKDVyiO78lo7ztAjWTE
miXCrqlgXDZjil0Ndc/06ly3DsNHbhA+JaDCN4pI0G1nMjnZHBqN6+TAmfBk1r1DbV8F5GPhj+S
opj1MN4hi+IxT4e+VIBqAvr+MX+MKog==
X-Google-Smtp-Source: AGHT+IGNJ8I67/O6JC1OjJ+DbUg/mmKAOyXdVaNyNtlq4l8kGf7i3HCyDHDmFQhARiMGiCzKCq4G/5XrDrCXvb141/M=
X-Received: by 2002:a05:6e02:1d1c:b0:3a7:2b12:78dd with SMTP id
e9e14a558f8ab-3a7480234f3mr61515445ab.11.1731788021688; Sat, 16 Nov 2024
12:13:41 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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
References: <f296f4b3-19a1-08e6-5ff0-32d1dccc1daa@gmail.com>
<2633393.Lt9SDvczpP@rogueboard> <CAGfcS_nEcdt6vcGWWmU-pT4rneJtALi9bNSD2OK5dt8kh-WB+Q@mail.gmail.com>
<1836185.3VsfAaAtOV@rogueboard>
In-Reply-To: <1836185.3VsfAaAtOV@rogueboard>
From: Rich Freeman <rich0@gentoo.org>
Date: Sat, 16 Nov 2024 15:13:30 -0500
Message-ID: <CAGfcS_mozLSF0S1dAMNEMtvS9+OFCdhhGGeBn1GwFPTTPZcbGA@mail.gmail.com>
Subject: Re: [gentoo-user] Seagate hard drives with dual actuators.
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 2cc69c48-6ed8-4118-bbd8-b2dce44cd39c
X-Archives-Hash: 836c369ab19befb3ba4a4aade0f47201
On Sat, Nov 16, 2024 at 2:47=E2=80=AFPM Michael <confabulate@kintzios.com> =
wrote:
>
> As I understand it from reading various articles, the constraint of havin=
g to
> write sequentially a whole band when a random block changes within a band
> works the same on both HM-SMR and the more common DM-SMR.
Correct.
> What differs with
> HM-SMR instructions is the host is meant to take over the management of r=
andom
> writes and submit these as sequential whole band streams to the drive to =
be
> committed without a read-modify-write penalty. I suppose for the host to=
have
> to read the whole band first from the drive, modify it and then submit it=
to
> the drive to write it as a whole band will be faster than letting the dri=
ve
> manage this operation internally and getting its internal cache full.
I doubt this would be any faster with a host-managed drive. The same
pattern of writes is going to incur the same penalties.
The idea of a host-managed drive is to avoid the random writes in the
first place, and the need to do the random reads. For this to work
the host has to know where the boundaries of the various regions are
and where it is safe to begin writes in each region.
Sure, a host could just use software to make the host-managed drive
behave the same as a drive-managed drive, but there isn't much benefit
there. You'd want to use a log-based storage system/etc to just avoid
the random writes entirely. You might not even want to use a POSIX
filesystem on it.
> This
> will not absolve the drive firmware from having to manage its own trim
> operations and the impact metadata changes could have on the drive, but s=
ome
> timing optimisation is perhaps reasonable.
Why would a host-managed SMR drive have ANY trim operations? What
does trimming even mean on a host-managed drive?
Trimming is the act of telling the drive that it is safe to delete a
block without preserving it. A host-managed drive shouldn't need to
be concerned with preserving any data during a write operation. If it
is told to write something, it will just overwrite the data in the
subsequent overlapping cylinders.
Trimming is helpful with drive-managed SMR because if the drive isn't
told to trim a block that is about to be overwritten due to a write to
a different block, then the drive needs to first read, and then
rewrite the block. Trimming tells the drive that this step can be
skipped, assuming ALL the blocks in that region have been trimmed.
> I don't know if SMRs use flash to record their STL status and data alloca=
tion
> between their persistent cache and shingled storage space. I would think=
yes,
> or at least they ought to. Without metadata written to different media, =
for
> such a small random write to take place atomically a whole SMR band will =
be
> read, modified in memory, written to a new temporary location and finally
> overwrite the original SMR band.
Well, drive-managed SMR drives typically have CMR regions for data
caching, and they could also be used to store the bitmap. Cheap
drives might not support trim at all, and would just preserve all data
on write. After all, it isn't performance that is driving the
decision to sneak SMR into consumer drives. Flash would be the most
sensible way to do it though.
--=20
Rich