Re: Unconsistent two-level write speed bouncing on softraid RAID1 SSD's

On 2021-06-10 11:49:59, Xavier Sanchez <xavier.s@mailoo.org> wrote:
>
> Read somewhere that issuing a security erase could also help. So I
> tried issuing the following:
>
> # atactl sd0c secsetpass user high
> User password:
> Retype user password:
> atactl: ATA device returned error register 0
>
> But any sec* command returned:
> atactl: ATA device returned error register 0
>
> even after a coldboot ( non-frozen ), despite the devices supports the
> Security Mode feature set
>
> - Am I attempting to issue the security erase the wrong way ?
>

This is not possible on OpenBSD. It's actually a feature, not a
bug. OpenBSD issues the secfreeze command at the driver level
when disks attach.

From atactl(8):

secfreeze
Prevents changes to passwords until a following power cycle.
The purpose of this command is to prevent password setting
attacks on the security system. After command completion any
other commands that update the device lock mode will be aborted.


You can see in src/sys/dev/ata/atascsi.c:408 and
src/sys/dev/ata/wd.c:305 that the same command is issued to all
sd(4) and wd(4) drives as a security measure.

You're going to need to boot from a live CD/USB in order to set a
password on the drive.

You should also double-check that your BIOS doesn't have a setting
to disable this too. I've heard that some BIOSes have a toggle
for this to help mitigate the above-mentioned password setting
attacks.

Also, another poster mentioned that these are SMR drives. If
that's the case, then the "stuttering" speeds you described is
normal for them. SMR drives are good for storing infrequently
accessed files. They're big and they're cheap, but they're not
always very fast.

Like the old saying goes when it comes to hard drives, "Pick any
two: cheap, fast, big". SMR drives write data in "stripes". If
you change even one bit of one byte anywhere in that stripe, the
drive has to read the entire stripe into memory, change what was
changed, then re-write the entire stripe.

This is a limitation of the technology they use. It allows very
high density drives, but has the drawback of slowing things down a
lot whenever the drive has to re-write a stripe of data.


I've personally found that SMR drives are good enough for my use
case, but I wouldn't recommend them for a live database where
latency is much more critical.

It seems like the new hierarchy is now:

SSD >> PMR > SMR

when it comes to speed. The inverse is true when it comes to
capacity.

So to summarize, your drive may be working exactly as intended.

--
Bryan