On Tue, 27 Jun 2017 14:07:24 +0200 Dan van der Ster wrote: > 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). > I thought about this as well and it is quite preferable to the "live" trim that's been suggested and is seemingly being worked on. If it were implemented I would still set it to false by default, since any sizable SSD actually needing TRIMs I can see being gone for tens of minutes if not an hour or more for really large ones. Something I wouldn't want to happen on a non-planned reboot. Christian -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Rakuten Communications _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |