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>