I just posted the patch to add an option to disable read caching. It works with all three cache polices, then you can get write-only. If you want read-only-operations, you can just use writearound policy. -Jianjian On Wed, Jul 16, 2014 at 11:30 AM, Hannes Tismer <panni@xxxxxxxxxxxxx> wrote: > I second that. > > This would make the whole process even more tunable. > > Also a "simple" feature to limit caching to only-write-operations or > only-read-operations > would be very nice to have also. > > > Hannes > > > > > > On Wed, 16 Jul 2014 11:19:16 -0500, Larkin Lowrey > <llowrey@xxxxxxxxxxxxxxxxx> wrote: > >> I am also interested in this use case and also would like to see >> separate sequential cutoff values for read and write. >> >> In addition to that I would like to offer another idea for >> consideration, high and low watermarks for writeback_percent. >> >> The documentation at http://bcache.evilpiepirate.org/Design/ is either >> out of date or incomplete... or I don't understand it. Specifically the >> meaning of writeback_percent is not clear to me. That documentation >> states that write-back will not begin until the writeback_percent >> threshold has been reached. The definition in bcache.txt states that >> bcache tries to maintain that percent of the cache dirty. The latter >> seems to match my observations so I'll go with that. >> >> My idea is to have high and low watermarks for writeback_percent where >> writeback would not begin until reaching the high watermark and writing >> would continue until the low watermark was reached. To match the present >> behavior, as I understand it, both values would be set the same. >> However, in the use case described here the spread between the two would >> define how often the backing store would need to be spun up for writing. >> >> If one writes 10GB a day and the spread between high and low >> writeback_percent watermarks is set to 10GB then the backing store would >> spin up only once per day. Ideally the writeback process would be able >> to write at a high rate in order to limit the amount of time the drives >> would need to be spinning. >> >> I see two competing priorities for writeback. One is to smooth writes so >> they are less bursty and less disruptive and the other is to consolidate >> writes so they can be done in batches (bursty). It would be great if >> both cases could be supported. >> >> --Larkin >> >> On 7/16/2014 7:19 AM, Hannes Tismer wrote: >>> >>> Dear bcache-developers, >>> >>> This is a feature request for a very specific use case: >>> >>> Having a caching device in front of an md-raid on a machine which >>> serves as a low power media server. >>> >>> The last writes could be cached on the caching device to reduce the >>> non-sleep time of the raid (drives in spindown state) while playing >>> media, together with a huge writeback delay of, let's say, 3 hours, >>> newest media would always be read from the caching device. >>> >>> It's not likely that a recently read (watched) media file will be read >>> again after having been read before (very recently), but it's very >>> likely that it'll be read once after it was written. >>> >>> I could disable sequential_cutoff or set it rediculously high. That >>> would result in every sequential read being cached into the caching >>> device, too, which in this use case is not wanted. >>> >>> Could you split up the sequential_cutoff setting to >>> sequential_read_cutoff and sequential_write_cutoff? >>> >>> That way writes including sequential ones can be cached for later, but >>> sequential reads could be ignored by the cache. >>> >>> >>> Thank you in advance >>> >>> Hannes > > > > -- > Hannes Tismer > Herzogstr. 4 > 41238 Mönchengladbach > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
