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 16:39:39 +0300 Message-ID: <56FA859B.5050608@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: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 thanks! Ric