Re: geli TRIM support
On 2014-03-21 11:53, RW wrote: On Thu, 20 Mar 2014 19:34:04 + 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@freebsd.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 signature.asc Description: OpenPGP digital signature
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 free...@allanjude.com wrote: On 2014-03-21 11:53, RW wrote: On Thu, 20 Mar 2014 19:34:04 + 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@freebsd.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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 free...@allanjude.com mailto:free...@allanjude.com wrote: On 2014-03-21 11:53, RW wrote: On Thu, 20 Mar 2014 19:34:04 + 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@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto: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 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
Re: geli TRIM support
On Thu, 20 Mar 2014 19:34:04 + 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
geli TRIM support
A while back there was talk of adding TRIM support to geli(8) [1]. Does anyone know if progress has been made or if there are still plans for it? [1] http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016773.html -- Greg Rivers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli TRIM support
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. 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. But for laptops with 1ssd only this is a problem I also read that new ssd's depending on the vendor might not need trim at all, but I'm not really sure how to tell. On 20 March 2014 18:21:51 WET, Greg Rivers gcr+freebsd-curr...@tharned.org wrote: A while back there was talk of adding TRIM support to geli(8) [1]. Does anyone know if progress has been made or if there are still plans for it? [1] http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016773.html -- Greg Rivers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
