Date: Sun, 16 Oct 2011 21:10:38 +0200 From: Florian Wagner <florian@wagner-flo.net> To: freebsd-fs@freebsd.org Subject: Re: [ZFS] Using SSD with partitions Message-ID: <20111016211038.05de98d2@naclador.mos32.de> In-Reply-To: <4E9B27D8.70106@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_//AIY9Dwzj2aC435CJeGIEvF
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
> > 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."
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:
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.
A correctly behaving drive should have at least as many data blocks on
disk as are displayed in the server application. Sometimes even more.
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.
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).
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.
Regards
Florian Wagner
--Sig_//AIY9Dwzj2aC435CJeGIEvF
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk6bLC4ACgkQLvW/2gp2pPxruACfVVrvI1bUhcgdGidrTQsd66AW
Dp8AoIu4cYPoD5XMH/vQgllpc1uXglqG
=BCeM
-----END PGP SIGNATURE-----
--Sig_//AIY9Dwzj2aC435CJeGIEvF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111016211038.05de98d2>