From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: Local SSD cache for ceph on each compute node. Date: Tue, 29 Mar 2016 18:35:03 +0300 Message-ID: <56FAA0A7.6050009@redhat.com> References: <1003879409.38672781.1458091493153.JavaMail.zimbra@redhat.com> <1517351774.38675790.1458092531934.JavaMail.zimbra@redhat.com> <8C4FE234-AC6A-4F80-84DA-DCB69C58E874@ebay.com> <054DE45B-30E4-44B6-88CE-23FC207FE41E@ebay.com> <56F792F6.9050400@redhat.com> <56FA46C9.6090500@redhat.com> <56FA6792.1050005@redhat.com> <56FA7DEA.9010005@redhat.com> <56FA859B.5050608@redhat.com> <9be96412.9Ro.9Gf.hp.1e3JYGxgKk@mailjet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9be96412.9Ro.9Gf.hp.1e3JYGxgKk-ImYt9qTNe79BDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ceph-users-bounces-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org Sender: "ceph-users" To: Nick Fisk , 'Sage Weil' Cc: ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org, 'device-mapper development' List-Id: dm-devel.ids On 03/29/2016 04:53 PM, Nick Fisk wrote: >> -----Original Message----- >> From: ceph-users [mailto:ceph-users-bounces-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org] On Behalf Of >> Ric Wheeler >> Sent: 29 March 2016 14:40 >> To: Nick Fisk ; 'Sage Weil' >> Cc: ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org; device-mapper development > devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> Subject: Re: [ceph-users] Local SSD cache for ceph on each compute node. >> >> On 03/29/2016 04:35 PM, Nick Fisk wrote: >>> One thing I picked up on when looking at dm-cache for doing caching >>> with RBD's is that it wasn't really designed to be used as a writeback >>> cache for new writes, as in how you would expect a traditional >>> writeback cache to work. It seems all the policies are designed around >>> the idea that writes go to cache only if the block is already in the >>> cache (through reads) or its hot enough to promote. Although there did >>> seem to be some tunables to alter this behaviour, posts on the mailing >>> list seemed to suggest this wasn't how it was designed to be used. I'm >>> not sure if this has been addressed since I last looked at it though. >>> >>> Depending on if you are trying to accelerate all writes, or just your > "hot" >>> blocks, this may or may not matter. Even <1GB local caches can make a >>> huge difference to sync writes. >> Hi Nick, >> >> Some of the caching policies have changed recently as the team has looked >> at different workloads. >> >> Happy to introduce you to them if you want to discuss offline or post >> comments over on their list: device-mapper development > devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> >> thanks! >> >> Ric > Hi Ric, > > Thanks for the heads up, just from a quick flick through I can see there are > now separate read and write promotion thresholds, so I can see just from > that it would be a lot more suitable for what I intended. I might try and > find some time to give it another test. > > Nick Let us know how it works out for you, I know that they are very interested in making sure things are useful :) ric