Re: Why is O_DSYNC on linux so slow / what's wrong with my SSD?

From: Stefan Priebe
Date: Fri Nov 22 2013 - 14:57:16 EST


Am 20.11.2013 16:55, schrieb J. Bruce Fields:
On Wed, Nov 20, 2013 at 10:37:03AM -0500, Theodore Ts'o wrote:
On Wed, Nov 20, 2013 at 08:52:36PM +0530, Chinmay V S wrote:

If you have confirmed the performance numbers, then it indicates that
the Intel 530 controller is more advanced and makes better use of the
internal disk-cache to achieve better performance (as compared to the
Intel 520). Thus forcing CMD_FLUSH on each IOP (negating the benefits
of the disk write-cache and not allowing any advanced disk controller
optimisations) has a more pronouced effect of degrading the
performance on Intel 530 SSDs. (Someone with some actual info on Intel
SSDs kindly confirm this.)

You might also want to do some power fail testing to make sure that
the SSD is actually flusing all of its internal Flash Translation
Layer (FTL) metadata to stable storage on every CMD_FLUSH command.

Some SSD's are also claim the ability to flush the cache on power loss:

http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-series-power-loss-data-protection-brief.html

Which should in theory let them respond immediately to flush requests,
right? Except they only seem to advertise it as a safety (rather than a
performance) feature, so I probably misunderstand something.

Yes but they all should make use and support CMD_FLUSH so it's slow on them too.

And the 520 doesn't claim this feature (look for "enhanced power loss
protection" at http://ark.intel.com/products/66248), so that wouldn't
explain these results anyway.

Correct i think intel simply ignores CMD_FLUSH on that drive - no idea why an they fixed this for their 330, 530, DC S3500 (all tested)

--b.


There are lots of flash media that don't do this, with the result that
I get lots of users whining at me when their file system stored on an
SD card has massive corruption after a power fail event.

Historically, Intel has been really good about avoiding this, but
since they've moved to using 3rd party flash controllers, I now advise
everyone who plans to use any flash storage, regardless of the
manufacturer, to do their own explicit power fail testing (hitting the
reset button is not good enough, you need to kick the power plug out
of the wall, or better yet, use a network controlled power switch you
so you can repeat the power fail test dozens or hundreds of times for
your qualification run) before being using flash storage in a mission
critical situation where you care about data integrity after a power
fail event.

IOW, make sure that the SSD isn't faster because it's playing fast and
loose with the FTL metadata....

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/