Re: [PATCH 2/2] - writeback delay

[Steven Wilton <swilton@fluentit.com.au>]

[-- Attachment #1.1: Type: text/plain, Size: 2152 bytes --]

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

On 03/03/16 22:25, Steven Wilton wrote:
> 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:
> https://github.com/eskyuu/linux/commit/565a6e57fa5a55bdd6656ae89a28543a9d871f52 
>
>
>
> 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
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel


[-- Attachment #1.2: Type: text/html, Size: 3241 bytes --]

[-- Attachment #2: dm-cache-target.patch --]
[-- Type: text/x-patch, Size: 561 bytes --]

diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 7755af3..7dab682 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -532,8 +532,8 @@ static void set_dirty(struct cache *cache, dm_oblock_t oblock, dm_cblock_t cbloc
 {
 	if (!test_and_set_bit(from_cblock(cblock), cache->dirty_bitset)) {
 		atomic_inc(&cache->nr_dirty);
-		policy_set_dirty(cache->policy, oblock);
 	}
+	policy_set_dirty(cache->policy, oblock);
 }
 
 static void clear_dirty(struct cache *cache, dm_oblock_t oblock, dm_cblock_t cblock)

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]