Re: geli TRIM support

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> 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 mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> 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
>
>