On Tue, 15 Dec 2020 16:48:11 +0000, bob prohaska wrote:

> AFAIK, SMR doesn't hurt performance until the drive starts re-writing
> previously-used sectors, rather like flash. If your drives haven't
> reached that point, they'll function roughly like CMR (also called PMR)
> devices. Given the capacity of SMR drives, it might make sense to just
> use them as approximately write-once devices.
>
I've no argument with that reasoning.

But I suspect there are situations where SMR track rewrites have a
greater throughput impact than that due to block remapping on SSD
storage, simply because, while the way SSD drives remap blocks tends to
distribute rewrites across the whole volume, if I've understood the
process correctly, SMR rewrites tend to stay localised on or near the
physical tracks occupied by the block being rewritten, so if a number of
rewrites are done to physically adjacent data blocks, I can see a
situation developing where te resulting series of track rewrites affect
each other adversely, which could set off an avalanche of forced rewrites
that really hammer throughput, not helped at all by the buffer tracks not
being available to deal with unrelated writes and/or rewrites.

Or something like that.

As a result, if you've got an EXT4 or other journalling filesystem on the
drive, particularly if the partitions are relatively full, you'll get the
performance slowdowns a lot sooner, simply because the rate of rewrites
will rise much faster than it ever does for cold data (transaction logs
etc) being recorded in a non-journalling file system where rewrites
hardly ever happen.

Its somewhat unclear to me what exactly TRIM is meant to improve when
used on an SMR drive: I can see that it would be a big help if it could
defragment files etc, but surely that can't be done at the drive level
since it implies some knowledge of the filing system's logical structure?


--
--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05