From owner-freebsd-current@FreeBSD.ORG Mon Mar 24 19:08:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6280680D for ; Mon, 24 Mar 2014 19:08:45 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 36D6ACEF for ; Mon, 24 Mar 2014 19:08:44 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B6AE2605F3; Mon, 24 Mar 2014 19:08:42 +0000 (UTC) Message-ID: <533082BE.5010108@allanjude.com> Date: Mon, 24 Mar 2014 15:08:46 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miguel Clara Subject: Re: geli TRIM support References: <20140321155348.2945e05e@gumby.homeunix.com> <533066FC.5040805@allanjude.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gPHVwapA1nbWkSG77MUCsSJaN5aB7FGUc" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:08:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gPHVwapA1nbWkSG77MUCsSJaN5aB7FGUc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-03-24 13:41, Miguel Clara wrote: > As I mention the laptop has TWO drives: 1 HDD and 1 SSD, which was why = I > wanted to try this setup. >=20 > But firstly I don't wan't geli+trim so I use the full HDD with zfs+geli= , > which means the SSD would be unused! >=20 > Before this setup I was using the SSD for the "system" with > UFS+trim+geli, but later I found that geli has no support for trim. and= > since my HDD had to be replaced, It got me thinking why not try to use = a > diferent setup myself... >=20 > Its true that the boot is much faster in a SSD, but my current setup is= > defiantly not slow, and I have enough memory just with the usually dail= y > usage, thing get different if I use ccache and start compiling stuff of= > course! >=20 > In any case what you point out about L2ARC (writes instead of reads) > does concern me, and was something I was aware off, and that's why I > keep regular backups, its mainly to test if the SSD can or cannot handl= e > it (at least until its on warranty). >=20 >=20 > As for the ZIL, I was under the impression that the purpose is not > cache, but to protect from data loss, am I wrong? > I found a very interesting article about this > actually: http://nex7.blogspot.nl/2013/04/zfs-intent-log.html. >=20 > Also my SSD has 19GB and AFAICT I wouldn't need that mcuh for the ZIL, > so why not partiton it?! >=20 > Anyway this is getting of topic, so perhaps we can continue this > discussing in other topic, I would really like to read you're toughs on= > this Alan, I am also awaere that illumos already supports persistent > L2ARC, I would be interested to know when this will be possible on > FreeBSD, but back to the geli issue... It would be nice to have > TRIM+GELI support, cause in that case I can use the full SSD with UFS > for the system and keep ports and other DATA on the HDD, since I > wouldn't need fast access to those! >=20 > Thanks >=20 >=20 >=20 >=20 >=20 > On Mon, Mar 24, 2014 at 5:10 PM, Allan Jude > wrote: >=20 > On 2014-03-21 11:53, RW wrote: > > On Thu, 20 Mar 2014 19:34:04 +0000 > > Mike C. wrote: > > > >> I was actually googling about this yesterday and found no more= info > >> then the thread you posted. > >> > >> So its seems that nothing was done related to this so far? > >> > >> Which means using trim+geli is problematic. > > > > These days SSD devices have static wear-levelling so you don't ne= ed to > > maximize the number of free blocks, just maintain a small pool. > You can > > do that by not partitioning the whole device and leaving a few pe= rcent > > unused. I'm not sure what you would do if the device had already = been > > written to though, if FreeBSD has a command to trim a device I do= n't > > know what it is. You could just use Linux's hdparm from a live CD= =2E > > > > You should also be OK if you have a non-geli UFS partition with > > sufficient free space on the same device. > > > >> I was using my ssd with UFS+trim+geli in my laptop. But even bef= ore > >> noticing the lack of support changed my setup... since the lapto= p has > >> both a ssd and hdd I am now using zfs+geli in the hdd. I have 2 > >> partitions in the ssd and I'm using it for log/cache. > > > > I've been considering that, but I did have a couple of concerns: > > > > 1. l2arc sounds like it would be much less effective outside of= > > servers because, AFAIK, the cache doesn't survive a reboot. > > > > 2. the l2arc cache turns reads on the filesystem into writes to = the > > SSD. > > > > > > _______________________________________________ > > freebsd-current@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " > > >=20 > 1. There is work to make a persistent L2ARC, but it is not finished= yet >=20 > 2. Having an L2ARC (or ZIL for that matter) on the same SSD that th= e > files are on, is only going to hurt. Using an L2ARC takes up more R= AM, > leaving less for the primary ARC, and as was pointed out about, tur= ns > reads into writes. Reading from the L2ARC partition is not going to= be > any faster than reading from the main data partition, so I don't se= e the > point. Same goes for writes to a ZIL. >=20 > If your laptop has only 1 drive, an SSD, then you probably just wan= t to > use the entire thing for the ZFS pool, rather than partitioning it = to > use the advanced features that are meant to use SSDs when the pool = is > NOT SSDs. >=20 > -- > Allan Jude >=20 >=20 With 1 HDD plus 1 SSD the situation is a bit different. Persistent L2ARC should be upstreamed to OpenZFS soon, and then pulled into FreeBSD. I don't know that anyone is working on it specifically thou= gh. The L2ARC doing a lot of writes is controlled, there are sysctls that throttle the SSD to avoid wearing it out too fast. The defaults here may infact be too conservative and reduce the usefulness on a laptop, so you may wish to turn them up. a ZIL is a type of write cache, what it does it accept synchronous writes (not asynchronous writes) quickly, so that the application can continue. It then flushes those writes out to the main pool. The idea here, is that if you have a database, that will not return from an UPDATE query until the data is safely on disk, writing to the SSD is faster and allows the next query to proceed, and then the data can be written out to the HDD after the fact. I have no comment on geli+TRIM. --=20 Allan Jude --gPHVwapA1nbWkSG77MUCsSJaN5aB7FGUc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTMILBAAoJEJrBFpNRJZKfBQYQAMP33oykwfGZUYAaEKjAHRfI XZd6WeTfETRaG6uQgjj2/3pboH1MOC03btIQBgFloMzgr7QRibwoqjPmQQyplCSa j//tsncVMkxTZwd2+Wz9FJwChd6N1meoFevPIPTT1h9l/jxPzLJqzsU31La4Xenj LXNL0iXwI1k8dSuc++1bPBmRb6yF1pONwDi60AInaFeeRf8M9ogCbk21IAPNLWfU yqr2oZRPIHfHDaODkpeB/e6f29qJFMnQyTKcOW9Yj5pqESC59VvocqGgRkd69c9z syS6tJAxx4/C5aJBZSHjNamJzD1/aZC46EH1pm6rWKXW6pOl4C/K72VviHfJtiqo h5CRk7hXfULE8A33yIrgEEs2OMQVs2cwRzaXvnp/e/MbaFzDj3w/6IkfqHMRddYd 0haRjDCUETRq0PTTj1pyJW2duCAzUW+mtXzmS0EVYBkN4rMNzWhYM1AARuFL5p2l NBh8EQwu6FyiHQTLo4FYRHtGNahUBkLlpAj3/j5wTtiMol9sRxuVlzz5MpKyERZa dQuj4KwZO7xIIg0V1Gp/mUAlSSgDly9qA9nPQoDArllasnqdwPBLjCMbgIYhVTW5 01hR+g8+SFcBFBVt2+eFw5yu+29ETb2nTuAtRCo+F/kNafPDzd89m30jkEUq7Puf 6HVGAuU3e/ESoZ5wYLIL =43qG -----END PGP SIGNATURE----- --gPHVwapA1nbWkSG77MUCsSJaN5aB7FGUc--