On Tue, Jun 27, 2017 at 1:56 PM, Christian Balzer <chibi@xxxxxxx> 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 <chibi@xxxxxxx>: >> > >> > >> > 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@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |