Date: Sun, 16 Oct 2011 17:22:59 -0400 From: Charles Sprickman <spork@bway.net> To: Florian Wagner <florian@wagner-flo.net> Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Using SSD with partitions Message-ID: <D11E1330-6FB5-462F-8878-BF70AD77B7B4@bway.net> In-Reply-To: <20111016211038.05de98d2@naclador.mos32.de> References: <CACh33Fpz=uAp8h0Bjsi1Be=ob_94jXtN51mAHvGPkReY5MpTcg@mail.gmail.com> <4E9AE725.4040001@gmail.com> <169E82FD-3B61-4CAB-B067-D380D69CDED5@digsys.bg> <4E9B1C1E.7090804@gmail.com> <20111016183003.GA29466@icarus.home.lan> <4E9B27D8.70106@gmail.com> <20111016211038.05de98d2@naclador.mos32.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 16, 2011, at 3:10 PM, Florian Wagner wrote: >>> 1) I would like a definition of what "unprotected SSD" means and >>> what a "protected SSD" is. >>=20 >> Let me better quote again, "Many high-end SSDs have backup batteries >> or capacitors to ensure that operations complete even if power fails. >> Our results argue that these systems should provide power until the >> chip signals that the operation is finished rather than until the = data >> appears to be correct. Low-end SSDs and embedded systems, however, >> often do not contain backup power sources due to cost or space >> constraints, and these systems must be extremely careful to prevent >> data loss and/or reduced reliability after a power failure." >=20 > I can provide a practical data point on this. I've tested power = failure > with some Corsair Force SSD. I've used one of the tools available for > that. The process goes like that: >=20 > 1. Start some kind of server application which waits for messages. > 2. Start a client application which in a loop does: > a. Write a block of data to disk. > b. Call fsync/fdatasync to make sure the written data is on this. > This systemcall sould block the application until all layers > (including) the disk driver and thus the disk signal the write > has completed. > c. Send a message to the server which then displays the block > number written. > 3. Cut power to the SSD. >=20 > A correctly behaving drive should have at least as many data blocks on > disk as are displayed in the server application. Sometimes even more. >=20 > For the tested SSD data blocks amounting to about 1 to 1.2 MB of data > were consistently missing even thought they were signaled to be on = disk. >=20 > Care was taken to ensure that all involved OS subsystems were capable > of handling the fsync/fdatasync calls correctly and passing them > to lower layers (which is not the case for all filesystems in older > versions of Linux for example). >=20 > I've just recently repeated the test for a Intel 320 drive (the 120 GB > version, but should be the same for all models) which includes a set = of > capacitors. These exhibit correct behavior. No missing data for about = a > dozen trials. This sounds like diskchecker: http://brad.livejournal.com/2116715.html There are finally some affordable drives (eg: $100 40GB for ZIL) that incorporate a capacitor that allows the drive to flush cache to flash. My understanding is that the Intel 320 series have this and supposedly some of the OCZ drives (Vertex Pro 2, Vertex Pro 3). Intel is the only one I'm finding that has an explicit declaration that data is safely flushed though: = http://newsroom.intel.com/servlet/JiveServlet/download/38-4324/Intel_SSD_3= 20_Series_Enhance_Power_Loss_Technology_Brief.pdf The PostgreSQL lists have some interesting info, as they are pretty conservative about the definition of "safe" writes. Also one of the devs posted this earlier this year: = http://blog.2ndquadrant.com/en/2011/04/intel-ssd-now-off-the-sherr-sh.html= For ZFS ZIL use, it also seems like mirroring is generally recommended. Since ZIL doesn't benefit from large drives, the lowest priced Intel 320 x2 is not a bank-breaker. Charles >=20 > Regards > Florian Wagner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D11E1330-6FB5-462F-8878-BF70AD77B7B4>