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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
