Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)

[Rich Freeman]

On Sat, Jul 31, 2021 at 12:58 AM William Kenworthy <billk@×××××××××.au> wrote:
>
> I am amused in a cynical way at disk manufacturers using decimal values ...
>

So, the disk manufacturers obviously have marketing motivations.
However, IMO the programming community would be well-served to just
join basically every other profession/industry on the planet and use
the SI units.  If you want to use GiB to measure things by all means
do so, but at least stick the "i" in your output.

You're not going to change ANYTHING by using SI decimal prefixes to
refer to base-2 units.  Everybody on the planet who isn't a programmer
is already using SI prefixes, recognizes SI as the authoritative
standards body, and most of the governments on the planet probably
have the SI prefixes enacted as a matter of law.  No court on the
planet is going to recognize even the most accomplished computer
scientists on the planet as speaking with authority on this matter.

All sticking to the old prefix meanings does is confuse people,
because when you say "GB" nobody knows what you mean.

Plus it creates other kinds of confusion.  Suppose you're measuring
recording densities in KB/mm^2.  Under SI prefixes 1KB/mm^2 equals
1MB/m^2, and that is why basically every engineer/scientist/etc on the
planet loves the metric system.  If you're going to use base-2 units
for bytes and base-10 for meters, now you have all sorts of conversion
headaches.  The base-2 system only makes sense if you never combine
bytes with any other unit.  I get that programming tends to be a bit
isolated from engineering and so we like to pretend that never
happens, but in EVERY other discipline units of measure tend to be
combined all the time, and it certainly happens in engineering real
computers that don't use infinitely long tapes and only exist in CS
textbooks.  :)

Just to combine replies: by "read-only" scrubbing I wasn't referring
to using "-r" but rather just that the scrub wasn't repairing
anything.  A scrub operation will repair problems it finds
automatically, and that would of course take a huge hit on SMR.  I'd
expect a scrub that doesn't encounter problems to perform similarly on
CMR/SMR, and something that does a ton of repair to perform terribly
on SMR.

Your numbers suggest that the SMR drive is fine for scrubbing without
errors (and if you have no mirroring/parity of data then you can't do
repairs anyway).  I'm guessing the drive was just busy while
scrubbing, and obviously a busy spinning disk isn't going to scrub
very quickly (that might be tunable, but if you prioritize scrubbing
then regular IO will tank - typically you want scrubbing at idle
priority).

-- 
Rich