Questions about erasing an ssd to restore performance under FreeBSD

[Steven Hartland]

----- Original Message ----- 
From: "Jeremy Chadwick" <freebsd at jdc.parodius.com>

> newfs -E is not the same thing as "Secure Erase" (issuing SECURE ERASE
> UNIT ATA command per ATA security data set spec).  newfs -E does exactly
> what the man page says it does: it writes zeros over every LBA on the
> disk (but it does so in blocks, not on a literal per-LBA basis; e.g. it
> does not write 512 bytes (LBA size) of zeros to LBA 0, then 512 bytes of
> zeros to LBA 1, etc. -- it does so in larger chunks).
> 
> The important thing to take away from this is that the FTL will not be
> reset to its factory-default configuration when erasing in this fashion.

It was my impression this was combined with a BIO_DELETE, which is
the key part I thought, but that seems to only be supported under ada?

> There are many factors to consider with SSDs when write speeds plummet.
> 
> The biggest and most noticeable is how much free space is available on
> the drive itself.  The less free space available, the worse wear
> levelling performs.  I just got done dealing with a person on the Intel
> Community Forums who complained of shoddy write performance, where lots
> of "techs" completely ignored the fact that his drive was showing 90%
> full (only 7GB left).

Not the case here, the drive has over 60% free space, but a large move of
data from one volume to many smaller volumes had just taken place. Still
suprisingly large drop, over 10x slower that it was.

> Is the /ssd partition actually aligned properly?  I want to assume it's
> UFS, not ZFS, given your earlier questions, but is the partition aligned
> to a 8KByte boundary?  (Most consumers tend to start their partitions at
> the 1MByte mark, but this is a bit overkill; I don't know what Corsair
> uses for NAND cell size nor erase page size, but with Intel the drives
> use 8KByte cells).

No its ZFS, and not exhibiting performance problems in the initial 6 months
or so alignment is not the issue in this case, only after the data move
yesterday did the lower performance get noticed.

> 
> Also, PRIOR to performing these tests, did you tunefs -t enable the
> filesystem?  It matters; TRIM is a much nicer way to ensure the drive
> restores itself to performance when LBAs on the drive become unused by
> the filesystem (rather than letting the internal drive GC "figure it
> out" as best as it can, it's always best to just tell the drive up front
> with TRIM what's no longer used.  Saves the FTL extra work)

ZFS so no TRIM support :(

> Is there some reason your tests couldn't just use /dev/urandom directly
> to absolutely positively rule out read I/O (from if=) being a potential
> limiting factor?  I absolutely believe you, but just sayin'...

Didn't realise there was a /dev/urandom, but /dev/random was very much
limited, which reading the man page makes sense now, something to remember
for next time :)

> Worth reading is this whitepaper, by the way.
> 
> http://www.stec-inc.com/downloads/whitepapers/Benchmarking_Enterprise_SSDs.pdf
> 
> By the way, your above dd is the first time I've seen an SSD write
> 1.8GBytes in 0.5 seconds.  Though I cannot rely entirely on benchmark
> reviews, the one I just skimmed indicated a fresh drive of your model
> tends to write, sequentially, at about 60MBytes/sec..

Hmm, I must have copied the wrong results there some where, here's
the correct one which shows 180MB/s, which is still lower than the spec's
285MB/s but its random data so not benefiting as much as it can from the
compression on the sandforce controller, most defintielty not 1.8GB/s ;-)

dd if=/data/test of=/ssd/test bs=1m         
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 5.542815 secs (189177506 bytes/sec)

As an update I've manged to get the drive back to full performance using
Parted Magic boot cd, but using the manual process shown on the following
page "instead" of using Disk Erase utility. Not sure why this didnt work
yet.
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Obviously having to boot to an alternative OS is far from ideal, so could
really do with a BSD solution that has the ability to secure erase the disk,
to restore performance, given the lack of TRIM in ZFS.

Is this something that could be added to camcontrol or may be its already
possible with "camcontrol cmd"?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.