Date: Fri, 21 Mar 2014 15:53:48 +0000 From: RW <rwmaillists@googlemail.com> To: freebsd-current@freebsd.org Subject: Re: geli TRIM support Message-ID: <20140321155348.2945e05e@gumby.homeunix.com> In-Reply-To: <d763caea-4e0b-4c36-a802-6032f896ecd1@email.android.com> References: <alpine.BSF.2.00.1403201257080.59665@roadkill.tharned.org> <d763caea-4e0b-4c36-a802-6032f896ecd1@email.android.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 need 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 percent 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 don't know what it is. You could just use Linux's hdparm from a live CD. 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 before > noticing the lack of support changed my setup... since the laptop 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140321155348.2945e05e>