Date: Wed, 27 Jul 2011 18:24:37 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD Message-ID: <20110728012437.GA23430@icarus.home.lan> In-Reply-To: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 27, 2011 at 11:39:46PM +0100, Steven Hartland wrote: > There seems to be loads of info about this but nothing concrete so > I'm hoping someone here can answer some questions:- > > 1. Does newfs -E work on all controllers or only in combination > with ahci ada driver? In our case the drivers are off an LSI controller > using the mpt driver > > mpt0: <LSILogic SAS/SATA Adapter> port 0xfc00-0xfcff mem 0xdf2ec000-0xdf2effff,0xdf2f0000-0xdf2fffff irq 16 at device 0.0 on pci2 > mpt0: [ITHREAD] > mpt0: MPI Version=1.5.18.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 0 Active Volumes (2 Max) > mpt0: 0 Hidden Drive Members (14 Max) > > 2. If newfs -E doesn't work, which I suspect is the case, is using > something like partedmagic boot cd and the secure erase app in that > still an option or is that again thwarted by the LSI controller? 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. > 3. If neither #1 or #2 work is there an alternative which will > without taking the drive out of the machine putting it in something > which supports ada and running one of the above on that machine? > > My current testing seems to indicate neither #1 or #2 work in this > case as write performance on Corsair SSD is still terrible after > both. If #1 does require ata then it would be good to note this in > the man page for newfs which currently indicates it will just work. > > da1 at mpt0 bus 0 scbus0 target 1 lun 0 > da1: <ATA Corsair CSSD-F60 2.0> Fixed Direct Access SCSI-5 device > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 57241MB (117231408 512 byte sectors: 255H 63S/T 7297C) > > By terrible I mean under 20MB/s sequential write speed where as a > new drive in a similar machine is showing closer to 200MB/s write > > oldssd# dd if=/data/test of=/ssd/test bs=1m > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 60.430616 secs (17351734 bytes/sec) 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). 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). 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) > newssd# dd if=/data/test of=/ssd/test bs=1m 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 0.555287 secs (1888349211 bytes/sec) > > In both tests /data/test was just created from /dev/random onto > a standard HD but is still in ARC so read speed is very high, hence > not the limiting factor. 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'... 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.. -- | 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110728012437.GA23430>