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 <free...@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. > > > > > > _______________________________________________ > > firstname.lastname@example.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@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 > > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"