Date: Tue, 19 Mar 2013 10:59:14 +0100 From: Thomas Steen Rasmussen <thomas@gibfest.dk> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: When will we see TRIM support for GELI volumes ? Message-ID: <514836F2.9080900@gibfest.dk> In-Reply-To: <20130319082732.GB1367@garage.freebsd.pl> References: <51479D54.1040509@gibfest.dk> <20130319082732.GB1367@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19-03-2013 09:27, Pawel Jakub Dawidek wrote: > On Tue, Mar 19, 2013 at 12:03:48AM +0100, Thomas Steen Rasmussen wrote: >> Hello there, >> >> I was happy to see TRIM support in UFS and ZFS, however: >> I would really like to see TRIM support for GELI volumes. > > At this point I am convinced that TRIM support should be added to GELI. Great! >> I finally got an SSD with TRIM support for the laptop, but I can't >> really use it with GELI disk encryption because the lack of TRIM >> support makes writing to the disk really slow after a while. > > This is not what I see. On one of my SSDs in my laptop I've two > partitions, both running ZFS, but one of them on top of GELI. > I don't use ZFS TRIM yet, as I see no slowdown whatsoever. > > How can you say this is lack of TRIM slowing your writes? > The performance degraded over time? Yes, the performance degraded a lot over time - in the beginning it was very fast, but as as soon as I had written the amount of space that the disk can hold, writes slowed down to a crawl. The disk was not full, data had been written and deleted, but once I had written approx the 120GB that is the size of the SSD, so it had to start deleting sectors to write, it got really slow. It still reads and for example boots fast, but if I download a large file on a fast connection, the entire machine freezes while it writes. I jumped on the SSD wagon pretty early, before the SSDs had TRIM support, so I have a good idea of what it "feels like". I have also confirmed that plain UFS with TRIM straight on the SSD (without GELI) is plenty fast on the same hardware. So I am indeed reasonably certain that this is caused by the lack of TRIM support. Pawel, on the system where you don't have TRIM enabled, but you still have decent performance: have you written more data than the capacity of the disk yet ? If not, the wear-levelling of the SSD just writes to fresh sectors and you will not notice a slowdown (yet). >> I've been told this is not a huge job, but I wouldn't know. > > It isn't. Great! :) > - Add -t and -T flags to geli init/onetime/configure subcommands. > -t will enable TRIM and -T will disable it. TRIM should be enabled by > default for providers that are only encrypted and disabled by default > for providers with integrity verification. > > - Add G_ELI_FLAG_TRIM flag that is set by default and configured using > new switches above. > > - Update g_eli.c to pass BIO_DELETEs down if the G_ELI_FLAG_TRIM flag is > set. If BIO_DELETE returns EOPNOTSUPP error, the G_ELI_FLAG_TRIM > should be removed from the in-memory structure (but not from on-disk > metadata, of course). This does sound pretty doable. Thank you for the info! /Thomas Steen Rasmussen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFINvIACgkQGjEBQafC9MC7+gCeOx0IbHRMl5JSLkybsZloKyKh xNEAn1hz9o9Az8sPjrKoj3L4Ao63h1K2 =w/U3 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?514836F2.9080900>