Re: [gentoo-user] Seagate hard drives with dual actuators.

[Rich Freeman <rich0@gentoo.org>]

On Sat, Nov 16, 2024 at 6:02 AM Michael <confabulate@kintzios.com> wrote:
>
> I assume (simplistically) with DM-SMRs the
> discard-garbage collection is managed wholly by the onboard drive controller,
> while with HM-SMRs the OS will signal the drive to start trimming when the
> workload is low in order to distribute the timing overheads to the system's
> idle time.

I'll admit I haven't looked into the details as I have no need for SMR
and there aren't any good FOSS solutions for using it that I'm aware
of (just a few that might be slightly less terrible).  However, this
doesn't seem correct for two reasons:

First, I'm not sure why HM-SMR would even need a discard function.
The discard command is used to tell a drive that a block is safe to
overwrite without preservation.  A host-managed SMR drive doesn't need
to know what data is disposable and what data is not.  It simply needs
to write data when the host instructs it to do so, destroying other
data in the process, and it is the host's job to not destroy anything
it cares about.  If a write requires a prior read, then the host needs
to first do the read, then adjust the written data appropriately so
that nothing is lost.

Second, there is no reason that any drive of any kind (SMR or SSD)
NEEDS to do discard/trim operations when the drive is idle, because
discard/trim is entirely a metadata operation that doesn't require IO
with the drive data itself.  Now, some drives might CHOOSE to
implement it that way, but they don't have to.  On an SSD, a discard
command does not mean that the drive needs to erase or move any data
at all.  It just means that if there is a subsequent erase that would
impact that block, it isn't necessary to first read the data and
re-write it afterwards.  A discard could be implemented entirely in
non-volatile metadata storage, such as with a bitmap.  For a DM-SMR
using flash for this purpose would make a lot of sense - you wouldn't
need much of it.

This is probably why you have endless arguing online about whether
discard/trim is helpful for SSDs. It completely depends on how the
drive implements the command.  The drives I've owned can discard
blocks without any impact on IO, but I've heard some have a terrible
impact on IO.  It is just like how you can complete the same sort
operation in seconds or hours depending on how dumb your sorting
algorithm is.

In any case, to really take advantage of SMR the OS needs to
understand exactly how to structure its writes so as to not take a
penalty, and that requires information about the implementation of the
storage that isn't visible in a DM-SMR.  Sure, some designs will do
better on SMR even without this information, but I don't think they'll
ever be all that efficient.  It is no different from putting f2fs on a
flash drive with a brain-dead discard implementation - even if the OS
does all its discards in nice consolidated contiguous operations it
doesn't mean that the drive will handle that in milliseconds instead
of just blocking all IO for an hour - sure, the drive COULD do the
operation quickly, but that doesn't mean that the firmware designers
didn't just ignore the simplest use case in favor of just optimizing
around the assumption that NTFS is the only filesystem in the world.

-- 
Rich