On Tue, Jun 27, 2017 at 1:56 PM, Christian Balzer <ch...@gol.com> wrote: > On Tue, 27 Jun 2017 13:24:45 +0200 (CEST) Wido den Hollander wrote: > >> > Op 27 juni 2017 om 13:05 schreef Christian Balzer <ch...@gol.com>: >> > >> > >> > On Tue, 27 Jun 2017 11:24:54 +0200 (CEST) Wido den Hollander wrote: >> > >> > > Hi, >> > > >> > > I've been looking in the docs and the source code of BlueStore to figure >> > > out if it issues TRIM/Discard [0] on SSDs and I haven't been able to >> > > find an answer. >> > > >> > > Does BlueStore/BlueFS issue these commands to give back the space to the >> > > underlying device? >> > > >> > > For SSDs it improves both write performance and their lifespan, so it >> > > would be a very nice to have feature. >> > > >> > > SATA 3.1 has "Queued TRIM Command" which allows it to be 'async' in the >> > > controller. >> > > >> > If it were that last bit, I'd be for it, if it isn't then something that >> > you can fully control akin to fstrim would be a much better idea. >> > >> >> Problem is that you can't run fstrim on BlueStore since it's not a mounted >> filesystem like XFS. Therefor TRIM/Discard would have to be issued by the >> OSD. >> > > I wrote akin, so lets call it bluetrim. > Bluestore already needs too know what blocks are allocated and which not, > so in a typical case stop the osd (noout first), run "bluetrim", fire it > up again. > Maximum speed of trim, no complex logic and most likely least amount of > client performance impact. >
How about [osd] bluestore trim on start = true (analogous to the omap/mon compactions). -- dan _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
