<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> I just realised that I had also made a change to dm-cache-target.c (attached) to make sure the policy set_dirty function is called every time we write to a cache block to ensure that the writeback time us updated for a hot block. Steve <div class="moz-cite-prefix">On 03/03/16 22:25, Steven Wilton wrote: </div> <blockquote cite="mid:56D84963.7000301@fluentit.com.au" type="cite">Hi, Please find attached a patch for the dm-cache mq policy that adds another config option of writeback_delay which adds a fixed delay for any write hits before a writeback will be performed. I have tested the patch on a development system, and confirmed that the writeback occurs after the configured time, and does not appear to cause any issues. I also confirmed that overwriting the same block delays the writeback indefinitely, while also avoiding the copy operation from SSD to HDD (which is my reason for creating the patch). I am interested to get confirmation that this patch does not have any glaring errors, and getting it merged if it is considered useful. The DEFAULT_WRITEBACK_DELAY option can be set to 0 if you want to merge the code without affecting the behaviour of existing deployments. The patch is available as a git commit here: <a class="moz-txt-link-freetext" href="https://github.com/eskyuu/linux/commit/565a6e57fa5a55bdd6656ae89a28543a9d871f52">https://github.com/eskyuu/linux/commit/565a6e57fa5a55bdd6656ae89a28543a9d871f52</a> The dm-cache policy could be improved further to defer writebacks until the cache is getting full (high/low watermarks), or trying to keep sequential dirty blocks together so we write them back sequentially. I am happy to develop and test along these lines if needed. I can confirm that this patch does make removing the cache more difficult, since the cache removal code waits for all writeback to complete before removing the cache. I had a look at the lvm2 code, and I'm not sure if the cleaner policy is meant to be applied before waiting for the writebacks to complete. At the worst case, the user-space program could be modified to set the writeback delay to 0, which would mirror the existing behaviour. regards Steven <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">-- dm-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/dm-devel">https://www.redhat.com/mailman/listinfo/dm-devel</a></pre> </blockquote> </body> </html>