Martin Gregorie  wrote:
> On Sun, 13 Dec 2020 16:38:29 +0000, bob prohaska wrote:
>
>> I attribute the acceptable performance to the drive being new,
>> with 1 TB capacity. Once it starts re-writing old sectors it'll likely
>> slow much more.
>>
> AFAIK trim isn't supposed to do anything useful to a hard drive
> regardless of speed or capacity, but I know nothing about SMR, except
> that an article I just read says its really only suitable for large scale
> data storage with minimal updating, i.e. not something I'd use for the
> (main? only?) storage volume for a Linux or Windows system and definitely
> not for a journalled fling system.
>
Practically, SMR is not readily avoidable. It's denser and therefore cheaper
than conventional perpendicular recording and has found its way, unbidden, to
a wide range of sizes, speeds and brands. The drawback is that, like flash,
data is written in relatively large blocks. Writes to an entirely unused
block proceed without a delay. Changes to an already-written block require
it be copied, edited and re-written in much the same fashion as flash, absent
the write fatigue problems of flash. Trim functions on an SMR drive much as
it does on a flash device, preemptively preparing new, empty blocks for prompt
use by consolidating partly-used blocks accumulated during earlier writes.

When something triggers a long period of sustained writes, like reconstructing
a raid array, this overwhelms the preparatory consolidation and slows writes
to a crawl. It's not that it doesn't work, rather that it works badly.

I should emphasize that this summary is my own interpretation of a random
selection of Internet research, and is therefore entirely suspect......


Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05