On Mon, Aug 31, 2015 at 08:53:54AM -0800, Kent Overstreet wrote: > > > - with a large enough amount of data, the 30 second writeback_delay may > > > be > > > insufficient; if it takes longer than that just to scan the entire > > > keyspace > > > it'll never get a chance to sleep. try bumping writeback_delay up and > > > see if > > > that helps. > > > > That shouldn't be the case when the amount of dirty data is below a > > gigabyte, or is it? > > No - it has to scan the entire btree, cached _and_ dirty data - so the > scanning > gets expensive when you have lots of clean cached data and very little dirty > data, so it's supposed to ratelimit to no more than one scan every 30 seconds > (IIRC; that algorithm has gone through a couple different iterations). But if > it's taking more than 30 seconds to complete one scan... well, you see the > problem?
That makes sense. The cache device is ~200 GB. I'll try to play with writeback_delay when the system is up and running again. Currently I'm doing a full backup such that I can test things without any worries. -- Vojtech Pavlik Director SuSE Labs -- 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
