lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 4 Jun 2013 15:19:36 -0400
From:	Theodore Ts'o <>
To:	Autif Khan <>
Subject: Re: Misbehaving SSDs - FTL corruption

On Mon, Jun 03, 2013 at 02:02:10PM -0400, Autif Khan wrote:
> We found that a relatively expensive Intel Enterprise SSD works perfectly.
> Some relatively inexpensive Crucial, OCZ and Sandisk SSDs do not.

Who knows?  You need to ask the SSD vendors; as a file system
developer, all I know is that after the disk lets us know that a
CACHE_FLUSH command has completed, everything is supposed to be on
stable store, including any FTL data.  

We have no other way of influencing what the storage device might
decide to do.

> Is there a separate command/syscall to tell the SSD to flush its FTL?

There is no separate SATA command.  Just the CACHE_FLUSH SATA command,
and this is what ext4 issues in response to a fsync(2) system call.

It may be that if you wait 30 seconds after the last disk write,
hopefully the crappy SSD has gotten around to writing out all of its
necessary data and metadata.  You shouldn't have to do that, but if
you have a crappy drive, you have a crappy drive.

Is there some reason you can use a controlled shutdown most of the

						- Ted
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists