Re: geli TRIM support

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.
> 
> 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!
> 
> 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...
> 
> 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 daily
> usage, thing get different if I use ccache and start compiling stuff of
> course!
> 
> 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 handle
> it (at least until its on warranty).
> 
> 
> 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.
> 
> Also my SSD has 19GB and AFAICT I wouldn't need that mcuh for the ZIL,
> so why not partiton it?!
> 
> 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!
> 
> Thanks
> 
> 
> 
> 
> 
> On Mon, Mar 24, 2014 at 5:10 PM, Allan Jude <freebsd_at_allanjude.com
> <mailto:freebsd_at_allanjude.com>> wrote:
> 
>     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 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.
>     >
>     >
>     > _______________________________________________
>     > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org>
>     mailing list
>     > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>     > To unsubscribe, send any mail to
>     "freebsd-current-unsubscribe_at_freebsd.org
>     <mailto:freebsd-current-unsubscribe_at_freebsd.org>"
>     >
> 
>     1. There is work to make a persistent L2ARC, but it is not finished yet
> 
>     2. Having an L2ARC (or ZIL for that matter) on the same SSD that the
>     files are on, is only going to hurt. Using an L2ARC takes up more RAM,
>     leaving less for the primary ARC, and as was pointed out about, turns
>     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 see the
>     point. Same goes for writes to a ZIL.
> 
>     If your laptop has only 1 drive, an SSD, then you probably just want 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.
> 
>     --
>     Allan Jude
> 
> 

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 though.

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.

-- 
Allan Jude