<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 20, 2022 at 9:45 AM Lakshmi Narasimhan Sundararajan <<a href="mailto:lsundararajan@purestorage.com">lsundararajan@purestorage.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Team!<br>A very good day to you.<div><br>I have a lvm cache setup with 14TB cache on a origin device that is 110TB.</div><div>The cache was configured with 1MB cache blocks, and 100MB migration bandwidth/smq policy/writeback. This setup has a large memory and high cpu count, so we relaxed the allocation/cache_pool_max_chunks to accommodate this. The setup was stable until the cache got full of dirty blocks.</div><div>Under some cases, cache target seems to block submitted IO and only do migration and all IO that's incoming seems to be very slow. <br>Does the cache target have a scenario where this may happen when the cache is full of dirty blocks?</div><div><br></div><div>It looks like the migration bandwidth was underprovisioned as the cache got full of dirty blocks. Now I am trying to flush the cache and bring down the dirty block count on a live setup. Below are some options I tried and would like feedback to know what's the best way to bring down the dirty blocks without taking down the node. <br><br></div><div><br></div><div>1/ increase migration threshold to a larger value 1600 MB.</div><div>2/ change cache policy to cleaner</div><div><div><br></div><div>Do these change take effect on the fly?</div><div></div></div><div>I do not seem to see the dirty block count drop significantly.</div><div><br>Can you please point me how to bring down the dirty block count immediately on a live setup? <br></div></div></blockquote><div><br>More findings from the scenario.<br>Cache is currently configured at cleaner policy, 1600MBps migration bandwidth, writeback mode.<br><br></div><div>Now in this state, it looks like the cache is still accumulating newer writes within. Can this be confirmed?</div><div>Q: Does writeback cache still accumulate newer writes while in cleaner policy? Does it only accumulate write overwrites for existing block in cache?<br>Or does it only accumulate write overwrites on dirty block only in cache?<br></div><div><br></div><div>And if yes, does reconfiguring cache to writethrough mode make sense with cleaner policy, to allow continual IO flush and maintaining data consistency for those in-flight dirty blocks?<br><br>Q: It looks like when writethrough gets configured with dirty blocks, the cli waits until flush gets complete before applying writethrough.<br>In my situation, this may take a very long time to drain. How can I ensure cache does not accumulate any newer writes but only drain all dirty data.</div><div><br></div><div>Please help me understand behavior in the above situation.</div><div><br>Regards</div><div>LN</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>Thanks for your help.</div><div>Regards</div><div>LN</div><div><br></div></div>
</blockquote></div></div>