Allow separation of sequential_cutoff

Allow separation of sequential_cutoff

[Hannes Tismer]

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

Re: Allow separation of sequential_cutoff

[Larkin Lowrey]

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

Re: Allow separation of sequential_cutoff

[Hannes Tismer]

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@nuclearwinter.com> 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

Re: Allow separation of sequential_cutoff

[Jianjian Huo]

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@fragstore.net> 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@nuclearwinter.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html