Questions about erasing an ssd to restore performance under
FreeBSD
Jeremy Chadwick
freebsd at jdc.parodius.com
Fri Aug 5 03:30:19 UTC 2011
On Fri, Aug 05, 2011 at 12:10:40AM +0100, Steven Hartland wrote:
> ----- Original Message ----- From: "Steven Hartland"
> >>Understood. I'm off work this week so I'll see if I can dedicate some
> >>time to it. Too many non-work projects I'm juggling right now, argh.
> >>
> >>I'll have to start with camcontrol since the test system I have uses
> >>ada(4) and not classic ata(4). I'm not even sure what I'm really in for
> >>given that I've never looked at camcontrol's code before.
> >>
> >>If I "brick" my SSD I'll send you a bill, Steven. Kidding. :-)
>
> We seem to be having this issue on more disks now so I thought I'd
> have a bash at it to see how far I could get. To my suprise I think
> I've pretty much got it all the ata security options added to camcontrol.
>
> The only outstanding issue seems to be cam / ata appears to have an
> overflow bug which limits timeouts to 2147 seconds or less which would
> likely cause issues for rotary disks.
>
> I've posted about this in a seperate thread
> "cam / ata timeout limited to 2147 due to overflow bug?"
>
> In the mean time would you be interested in reviewing the code Jeremy?
I can try. I started working on it myself last weekend and ended up
experiencing some anomalies that required me to mail mav at . My request
CDBs through CAM were being rejected with ABRT (which can happen per ATA
specification when certain criteria aren't met). However, CAM includes
the request CDB bytes when such occurs, and the bytes I sent with my CDB
did not match in any way shape or form what CAM was insisting I had
sent.
I was doing my testing using "camcontrol cmd", since I didn't want to
write a bunch of code if I could at least confirm behaviour with cmd.
I was making the assumption that if I gave cmd a 512-byte CDB but only
provided, say, 15 or 16 of the initial bytes, that the kernel or CAM
layer would zero out the rest of the 512-byte CDB. I asked mav@ and he
wasn't sure if this was the case. I've included the Email between him
and I below (I hope he doesn't mind).
I did not have time to try providing all 512 bytes, but I did remove my
erroneous "ff ff" bytes (set to "00 00" instead) and it made no
difference.
The code I wrote for viewing the ATA Security Feature Set bits works
fine (wasn't hard to implement). I based my code on what Linux hdparm
had.
I can put that patch up on the web, but be aware it's more of a "hack"
because /usr/include/sys/ata.h needs certain bits added to it, which I
just defined in camcontrol.c for the time being. There's also user
interface pieces which are half-written which I need to remove. I
wouldn't want people patching their camcontrol for this functionality
with a half-ass patch is what I'm saying. :-)
icarus# ~jdc/work/camcontrol/camcontrol identify ada0
{...}
Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
overlap no
Tagged Command Queuing (TCQ) no no
Native Command Queuing (NCQ) yes 32 tags
SMART yes yes
microcode download yes yes
Security Mode feature set yes no
power management yes yes
advanced power management no no
automatic acoustic management no no
media status notification no no
power-up in Standby no no
write-read-verify no no
unload yes yes
free-fall no no
data set management (TRIM) yes
ATA Security Features Status/Value
master password revision 0xfffe
locked no
frozen no
password attempt exceeded no
enhanced erase support yes
security level high
erase unit time 2 minutes
enhanced erase unit time 2 minutes
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Date: Fri, 29 Jul 2011 12:36:21 +0300
From: Alexander Motin <mav at FreeBSD.org>
To: Jeremy Chadwick <freebsd at jdc.parodius.com>
Subject: Re: Question about "camcontrol cmd" and ATA CDBs
Jeremy Chadwick wrote:
> Alexander,
>
> I've been working on implementing the ATA Security Feature set commands
> to camcontrol so folks can accomplish Secure Erase for their SSDs. To
> test things, I've been using "camcontrol cmd" to issue ATA CDBs to the
> drive along with data/payload, while also following the Linux hdparm
> source code (what a mess!).
>
> However, my drive is continually returning ABRT when issuing command
> 0xf1 (SECURITY_SET_PASSWORD) to set the user password.
>
> The ATA specification states this can happen if the Security feature set
> is in LOCKED or FROZEN mode, but that doesn't appear to be true. I've
> modified camcontrol to show the state of the Security set features
> (IDENTIFY word 128 and friends), so you'll see some extra output below
> that isn't in normal camcontrol.
>
> # ~jdc/work/camcontrol/camcontrol identify ada4
> pass4: <INTEL SSDSA2CW080G3 4PC10302> ATA-8 SATA 2.x device
> pass4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
>
> protocol ATA/ATAPI-8 SATA 2.x
> device model INTEL SSDSA2CW080G3
> firmware revision 4PC10302
> serial number CVPR112001WZ080BGN
> WWN 500151795950e88f
> cylinders 16383
> heads 16
> sectors/track 63
> sector size logical 512, physical 512, offset 0
> LBA supported 156301488 sectors
> LBA48 supported 156301488 sectors
> PIO supported PIO4
> DMA supported WDMA2 UDMA6
> media RPM non-rotating
>
> Feature Support Enabled Value Vendor
> read ahead yes yes
> write cache yes yes
> flush cache yes yes
> overlap no
> Tagged Command Queuing (TCQ) no no
> Native Command Queuing (NCQ) yes 32 tags
> SMART yes yes
> microcode download yes yes
> Security Mode feature set yes no
> power management yes yes
> advanced power management no no
> automatic acoustic management no no
> media status notification no no
> power-up in Standby no no
> write-read-verify no no
> unload yes yes
> free-fall no no
> data set management (TRIM) yes
>
> ATA Security Features Status/Value
> master password revision 0xfffe
> locked no
> frozen no
> password attempt exceeded no
> enhanced erase support yes
> security level high
> erase unit time 2 minutes
> enhanced erase unit time 2 minutes
>
> The extra output here comes from bits per master_passwd_revision,
> security_status, erase_time, and enhanced_erase_time fields of
> ata_params (include/sys/ata.h).
>
> Here's the camcontrol CDB I'm submitting:
>
> camcontrol cmd ada4 -v -r - \
> -a "f1 00 00 00 00 00 00 00 00 00 00 00" \
> -o 512 "00 00 45 69 6e 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff"
>
> The CDB should be:
>
> command = 0xf1
> feature = unused
> count = unused
> lba = unused
> device = the usual :-)
>
> The payload should be:
>
> byte 0 = 0x00 = bits 7-1 = n/a
> bit 0 = set USER password identifier
> byte 1 = 0x00 = bits 15-9 = n/a
> bit 8 = master pass capability HIGH
> byte 2-33 = 0x45696e73... = password string ("Eins" in ASCII)
> byte 34 = 0xff = low byte of master password revision + 1
> byte 35 = 0xff = high byte of master password revision + 1
Valid from 0001 to fffe. But only in <aster mode.
> byte 36-511 = I assume CAM zeros these out, so they should be 0x00 ?
I haven't experimented. You may try to use 512bytes file.
> What I get back:
>
> camcontrol: error sending command
> (pass4:ahcich4:0:0:0): NOP. ACB: 00 00 c0 a0 00 00 00 00 00 58 c0 a0
> (pass4:ahcich4:0:0:0): CAM status: ATA Status Error
> (pass4:ahcich4:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
> (pass4:ahcich4:0:0:0): RES: 51 04 c0 a0 00 00 00 00 00 c0 a0
Something is wrong there. You should see your command after "ACB:".
> I assume I'm doing something wrong but I've been scratching my head for
> a couple hours now trying to figure out the issue. Byte ordering? I'm
> not sure. cam_cdbparse() does not do a very good job explaining the
> exact ATA CDB byte order. I've power-cycled the device as well to no
> avail.
CDB byte order described in camcontrol(8). Data block transferred as-is.
> Also, the NOP seems to be because src/sys/dev/ata/ata-queue.c lacks
> relevant case statements for the Security Feature set commands. I can
> submit a simple PR/patch for improving those.
To the hell ata-queue.c :) cam/ata/ata_all.c seems has them.
--
Alexander Motin
More information about the freebsd-fs
mailing list