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 ...
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 ...
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 ...
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 ... with SMR for every track you rewrite
you have to salvage the neighbouring track too ...
Cheers,
Wol
