Re: solid-state drives
On Fri, 3 Aug 2012 19:17:53 +0200, users-err...@crater.dragonflybsd.org wrote: Well, dedup has fairly low overhead so that would be fine on a SSD too, but because SSD's tend to be smaller than HDDs there also tends to be not so much data to dedup so you might not get much out of enabling it. Great! I will add a page to the online documentation on ssds. Looking at the mailing list archive I see that threads like these aren't uncommon and there's been a lot of great conversations on the subject. Cheerio, Jelle
Re: solid-state drives
On 08/03/2012 09:39 AM, Jelle Hermsen wrote: You will definitely want to turn pruning on, it doesn't do all that much I/O and its needed to clean up the fine-grained snapshots. Rebalance, dedup, and recopy can be left turned off. Thanks for all these great tips. I'm building a new workstation and I'll probably buy an ssd and use it as root. I'm thinking about maximizing the amount of ram and then use tmpfs for /tmp. This will (hopefully) still leave me with enough memory to avoid swapping all together so I can put the swap partition on a spinning platter drive. The only thing that still leads me to doubt is the fact that I won't be able to use dedup on the ssd and compared to using a couple of 10,000rpm disks in raid 0 the random write performance is not that impressive. Cheers, Jelle
Re: solid-state drives
On Friday 03 August 2012 04:19:22 Jelle Hermsen wrote: Thanks for all these great tips. I'm building a new workstation and I'll probably buy an ssd and use it as root. I'm thinking about maximizing the amount of ram and then use tmpfs for /tmp. This will (hopefully) still leave me with enough memory to avoid swapping all together so I can put the swap partition on a spinning platter drive. The only thing that still leads me to doubt is the fact that I won't be able to use dedup on the ssd and compared to using a couple of 10,000rpm disks in raid 0 the random write performance is not that impressive. I don't see why you can't, or shouldn't, dedup an SSD. Deduping looks for identical sectors and frees one of them; since an SSD is completely random-access, there's no penalty for having some sectors far from the file's inode. Recopying an SSD is what makes no sense. Pierre -- sei do'anai mi'a djuno puze'e noroi nalselganse srera
Re: solid-state drives
On 08/03/2012 02:04 PM, Pierre Abbat wrote: I don't see why you can't, or shouldn't, dedup an SSD. Deduping looks for identical sectors and frees one of them; since an SSD is completely random-access, there's no penalty for having some sectors far from the file's inode. Recopying an SSD is what makes no sense. I'm just following Matt's advice here. But it has to do with reducing the amount of write operations on the ssd. The more succesful the deduping is, the more write operations it will take, and the quicker the ssd will wear out, I guess. But I really have no idea of the amount of operations that are in play here and what the relative increase in write ops is when you turn dedup on. It would be interesting to test/diagnose. If there's, say, only a 5% percent increase in write ops when you turn on dedup, then its benefits could be interesting enough to turn it on, because it could also leave you with extra room on the ssd to compensate for the total wear. Cheers, Jelle
Re: solid-state drives
Well, dedup has fairly low overhead so that would be fine on a SSD too, but because SSD's tend to be smaller than HDDs there also tends to be not so much data to dedup so you might not get much out of enabling it. -- The SSD's biggest benefit is as a cache, though I don't discount the wonderfully fast boots I get with SSD-based roots on my laptops. Random access read I/O on a SSD is several orders of magnitude faster than on a HDD (e.g. 20,000+ iops vs 250-400 iops)... that's a 50x factor and a 15K rpm HDD won't help much. Random write I/O is a bit more problematic and depends on many factors, mainly related to how well the SSD is able to write-combine the I/O requests and the size of the blocks being written. I haven't run any tests in this regard, but something like the OCZ's with their massive ram caches (and higher power requirements) will likely do better with random writes than, e.g. the Intel SSDs which have very little ram. Linear read and write I/O between a SSD and a HDD are closer. The SSD will be 2x-4x faster on the linear read I/O (instead of 50x faster), and maybe 1.5-2x faster for linear write I/O. NOTE! This is for a reasonably-sized SSD, 200GB or larger. SSD performance is DIRECTLY related to the actual number of flash chips in the SSD, so there is a huge difference in the performance of, say, a 200GB SSD verses the performance of a 40GB SSD. A 40GB SSD can be limited to e.g. 40 MBytes/sec writing. A 200GB SSD with a 6GBit/sec SATA phy can do 400 MBytes/sec writing and exceed 500 MBytes/sec reading. Big difference. -Matt Matthew Dillon dil...@backplane.com
Re: solid-state drives
On Wed, Aug 01, 2012 at 06:16:13PM -0400, Pierre Abbat wrote: This is a spinoff of the Aleutia question, since Aleutia puts SSDs in computers. How does the periodic Hammer job handle SSDs? Does reblocking do anything different than on an HDD? If a computer has an SSD and an HDD, which should get the swap space? Pierre On my workstation I use an SSD for the root filesystem, swapcache and /usr/pkg. The current configuration has snapshots set to 1d (10d retention time) and reblocking is set to 7d (1m runtime). All other option (prune, rebalance, dedup and recopy) are disabled. Currently it is running fine, but in my opinion running swapcache on a workstation that just runs for a couple of hours is not always necessary. I'm just running this setup to play with the swapcache and the SSD, because I think it is a very nice feature. Regards, Sven
Re: solid-state drives
:On Wed, Aug 01, 2012 at 06:16:13PM -0400, Pierre Abbat wrote: : This is a spinoff of the Aleutia question, since Aleutia puts SSDs in : computers. How does the periodic Hammer job handle SSDs? Does reblocking do : anything different than on an HDD? If a computer has an SSD and an HDD, which : should get the swap space? : : Pierre : :On my workstation I use an SSD for the root filesystem, swapcache and :/usr/pkg. : :The current configuration has snapshots set to 1d (10d retention time) :and reblocking is set to 7d (1m runtime). All other option (prune, :rebalance, dedup and recopy) are disabled. : :Currently it is running fine, but in my opinion running swapcache on a :workstation that just runs for a couple of hours is not always :necessary. I'm just running this setup to play with the swapcache and :the SSD, because I think it is a very nice feature. : :Regards, :Sven You will definitely want to turn pruning on, it doesn't do all that much I/O and its needed to clean up the fine-grained snapshots. Rebalance, dedup, and recopy can be left turned off. -Matt Matthew Dillon dil...@backplane.com
Re: solid-state drives
:This is a spinoff of the Aleutia question, since Aleutia puts SSDs in :computers. How does the periodic Hammer job handle SSDs? Does reblocking do :anything different than on an HDD? If a computer has an SSD and an HDD, which :should get the swap space? : :Pierre :-- :lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko It depends on the purpose. I run several laptops with both swap and root on the SSD. Obviously swapcache is turned off in that situation. I usually adjust the hammer config to turn off the 'recopy' feature and I usually set the reblocker to run less often, but that's about it. I only suggest running a hammer filesystem on a SSD under carefully controlled conditions... that is, not if you are going to be manipulating any large databases that could blow out the SSD. Normal laptop use should work fine but one always has to be cognizant of the SSD's limited write cycles. -- For machines that are working harder or which need a lot of disk space I run hammer on the HDD and put swap on the SSD, and enable swapcache. The SSD works very well as a cache under these circumstances. You still need to avoid heavy paging due to running programs which are too big to fit into memory, since that can wear out the SSD. This is my preferred setup. All the DragonFly boxes run with SSD-based swap and swapcache turned on. -Matt Matthew Dillon dil...@backplane.com
