Re: discard synchronous on most SSDs?

["Holger Hoffstätte" <holger.hoffstaette@googlemail.com>]

On Fri, 14 Mar 2014 21:21:16 -0700, Marc MERLIN wrote:

> On Fri, Mar 14, 2014 at 08:46:09PM +0000, Holger Hoffstätte wrote:
>> On Fri, 14 Mar 2014 15:57:41 -0400, Martin K. Petersen wrote:
>> 
>> > So right now I'm afraid we don't have a good way for a user to
>> > determine whether a device supports queued trims or not.
>> 
>> Mount with discard, unpack kernel tree, sync, rm -rf tree.
>> If it takes several seconds, you have sync discard, no?
> 
> Mmmh, interesting point.
> 
> legolas:/usr/src# time rm -rf linux-3.14-rc5 real	0m1.584s user	
0m0.008s
> sys	0m1.524s
> 
> I remounted my FS with remount,nodiscard, and the time was the same.
> 
>> This changed somewhere around kernel 3.8.x; before that it used to be
>> acceptably fast. Since then I only do batch trims, daily (server) or
>> weekly (laptop).
> 
> I'm never really timed this before. Is it supposed to be faster than
> 1.5s on a fast SSD?

No, ~1s + noise is OK and seems normal, depending on filesystem and
phase of the moon. To contrast here is the output from my laptop,
which has an old but still-going-strong Intel G2 with ext4:

$smartctl -i /dev/sda | grep ATA
ATA Version is:   ATA/ATAPI-7 T13/1532D revision 1
SATA Version is:  SATA 2.6, 3.0 Gb/s

without dicard:
rm -rf linux-3.12.14  0.05s user 1.28s system 98% cpu 1.364 total

remounted with discard & after an initial manual fstrim:
rm -rf linux-3.12.14  1.90s user 0.02s system 2% cpu 1:07.45 total

I think these numbers speak for themselves. :)

It's really good to know that SATA 3.1 apparently fixed this.

cheers
Holger