Aha, Setting mode to writethrough does cause all writes to be written to both cache and backing disk simultaneously - so not what I was looking for.
However, it seems the congestion option is what I was looking for. Setting cache_mode to writeback and then setting both congested_[read/write]_threshold_us to 0 as you directed seems to do pretty much exactly what I want. (at least it appears that almost all writes are going to cache first and then starts sending the data to the backing store about 30 seconds later as expected) Perfect, thank-you. Any chance you could briefly explain what the two congestion values do? Cheers, James -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Sefton Sent: 03 November 2012 23:07 To: Kent Overstreet Cc: [email protected] Subject: RE: Always cache? Okay, I will give that a try now. I thought write through caused immediate write to backing device though? Maybe I understood it wrong. Will confirm either way. Cheers, James -----Original Message----- From: Kent Overstreet [mailto:[email protected]] Sent: 03 November 2012 22:41 To: James Sefton Cc: [email protected] Subject: Re: Always cache? Hey - set cache_mode to writethrough, and then if you really want everything to hit the cache, also set both congested_thresholds to 0 On Sat, Nov 3, 2012 at 11:53 AM, James Sefton <[email protected]> wrote: > Hi Kent, > > I am trying to configure the cache to always cache. > The only time I want it to bypass the cache is when it has to. (ie.. > cache > full) > > In particular - I want all writes to hit the writeback cache and never > be written directly. (Unless no space is left for writeback) > > I am not sure how to configure this. I thought I had done it once > before but I cant seem to reproduce it. > > Here are my settings so far: > > /sys/block/bcache0/bcache/ > > cache_mode = writethrough [writeback] writearound none readahead = 0 > running = 1 sequential_cutoff = 0 (also tried this at 1.1G, which > appears to be maximum) sequential_merge = 1 (also tried 0. I have no > idea what this means) state = clean writeback_delay = 30 > writeback_metadata = 1 (not sure what this does) writeback_percent = > 40 (also tried at 10) writeback_running = 1 > > > not sure what else there is to configure. > Any suggestions would be appreciated. > > I am basically trying to maintain responsive disk access as much as possible. > The backing storage is on a slow link to a SAN and when accessed > directly is relatively slow. I want it to use the cache as much as is > possible and then bCache write the cache data to the backend storage > behind the scenes. Workload is mixed.. random and sequential reads > and writes, anything from just a few bytes to 4-5Gb files. > > I am guessing that sequential_cutoff = 0 disables the cut-off feature. > (I tried the max of 1.1G too, just in case) > > I am using nmon to monitor where data is being written while copying /usr into > the filesystem on cache0p1. (ext4) I am seeing writes going to the cache > device and the backing device simultaneously - but the cache is not > written to heavily. Performance seen when copying is similar to that > of if I was just writing to the backing device directly. (maybe a > little better since some bits are getting written to the cache) > > Any suggestion what I may be doing wrong? > > Cheers, > > James > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-bcache" in the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
