On Sat, Jul 31, 2021 at 12:58 AM William Kenworthy <[email protected]> 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
