Re: [gentoo-user] Testing a used hard drive to make SURE it is good.

[Rich Freeman]

On Tue, Jun 16, 2020 at 7:38 PM antlists <antlists@××××××××××××.uk> wrote:
>
> On 16/06/2020 13:25, Rich Freeman wrote:
> > And of course the problem with these latest hidden SMR drives is that
> > they generally don't support TRIM,
>
> This, I believe, is a problem with the ATA spec. I don't understand
> what's going on, but something like for these drives you need v4 of the
> spec, and only v3 is finalised. Various people have pointed out holes in
> this theory, so you don't need to add to them :-) But yes, I do
> understand that apparently there is no official standard way to send a
> trim to these drives ...

You might be right, but I thought that some drive-managed SMR drives
did support TRIM.  It seems just as likely that TRIM support was not
implemented to conceal the fact that the drives are SMR.

>
> > so even repeated sequential writes
> > can be a problem because the drive doesn't realize that after you send
> > block 1 you're going to send blocks 2-100k all sequentially.  If it
> > knew that then it would just start overwriting in place obliterating
> > later tracks, since they're just going to be written next anyway.
>
> No it can't do that. Because when it overwrites the end of the file it
> will be obliterating other random files that aren't going to be
> overwritten ...

Yes and no.

First, all but the last few tracks can definitely be written without
worry.  The last few tracks might need to be cached but that is far
less seeking than caching the whole thing.

Second, if the writes end on an SMR zone boundary, then nothing will
need rewriting.  This is of course how things are handled on
host-managed SMR drives - you just try to avoid the partial writes in
the first place.

>
> > Instead this drive is going to cache every write until it can
> > consolidate them, which isn't terrible but it still turns every seek
> > into three (write buffer, read buffer, write permanent - plus updating
> > metadata).
>
> Which IS terrible if you don't give the drive down-time to flush the
> buffer ...

It is less terrible than completely random writes, which is my point.
The drive requires far less time to flush the buffer if it is doing
large sequential writes, because only tail ends of a few regions might
need to be preserved.

>
> > If they weren't being sneaky they could have made it
> > drive-managed WITH TRIM so that it worked more like an SSD where you
> > get the best performance if the OS uses TRIM, but it can fall back if
> > you don't.  Sequential writes on trimmed areas for SMR should perform
> > identically to writes on CMR drives.
>
> You're forgetting one thing - rewriting a block on SSD or CMR doesn't
> obliterate neighbouring blocks

Actually, SSDs have exactly the same problem - you cannot rewrite one
block on an SSD without obliterating neighboring blocks.  The
differences are:

1.  The size of these regions is much smaller, so the amount of data
that needs to be read and rewritten is much smaller.  One block of
rewrite might be amplified to hundreds of kilobytes, not hundreds of
megabytes.
2.  SSDs have no seek penalties, so the cost of these extra
reads+writes are much lower in absolute terms, but you're still
getting write amplification.
3.  The SSDs aren't accumulating a large cache over time that can
cause performance to hit a wall for a long time.  The SSD just delays
every write it gets as needed, because these write delays all the time
aren't as noticeable.
4.  SSDs clearly advertise these issues and filesystems were updated
to support TRIM and mitigate them before they were adopted en masse.

#4 is really a big one.  Filesystems that aren't optimized for SSD can
have very noticeable performance drops.  Now, that is all relative - a
non-aware filesystem on SSD is still going to perform way better than
it does on any hard drive, so people switching to SSD from hard drives
are still going to be very happy.  If you are doing benchmarking
though you'll definitely see an issue if you're doing random writes on
SSDs without a filesystem that supports TRIM/etc.

> ... with SMR for every track you rewrite
> you have to salvage the neighbouring track too ...

More than just one neighboring track.  It really is the same issue as
SSD, except:

1.  All the issues are amplified by the seek latency of hard drives.
2.  The overall move from CMR->SMR is 100% downside in performance,
compared to the move from CMR->SSD where the downside is offset by a
much larger upside, so even a dumb implementation feels like a massive
improvement.

In any case, none of this really changes the fact that drive-managed
SMR really shouldn't be a thing at all, and it certainly shouldn't be
an unlabeled "feature."  SMR should have just been introduced as
host-managed as a way to offer cheaper storage for those who have the
use cases and filesystems that can manage it.  There is nothing wrong
with tape for storage, but if you stuck a tape drive preloaded with a
tape in a box that could speak ATA and called it a USB3 external "hard
drive" you'd drive people crazy.

-- 
Rich