dm-cache + storage client experiment

dm-cache + storage client experiment

[mlody3k .]

[-- Attachment #1.1: Type: text/plain, Size: 1079 bytes --]

Hi dm developers!

I'm during the experiment with dm-cache and storage client and I would be
very grateful if some of You will help me with some of my questions :).

Simply, I would like to implement the write-through caching in the client
where:
 - dm-cache is only responsible to check whether requested data is in the
cache device (return requested data if hit, ENODATA if miss - do not read
from origin) - in case of miss, my client will read data from the origin.
 - dm-cache will write only to the cache device - client will write data to
the origin.

Easily, I need to start dm-cache in writethrough mode without determining
the origin device. More specifically, I need to make two changes in dm code:
 - Bypass the origin device while writing data
 - Do not remap the result to the origin device in case of read miss.

So here's my questions:
 - Do the similar solution exists?
 - Do I have to change the policy code or maybe all of this things are
contained in the target code?
 - Could someone reproduce the IO path in dm-cache code?

Thanks for your help!
Regards,
JJ

[-- Attachment #1.2: Type: text/html, Size: 1338 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: dm-cache + storage client experiment

[John Stoffel]

>>>>> "mlody3k" == mlody3k  <mlody3k@gmail.com> writes:

mlody3k> Hi dm developers!
mlody3k> I'm during the experiment with dm-cache and storage client and I would be very grateful if some of
mlody3k> You will help me with some of my questions :). 

mlody3k> Simply, I would like to implement the write-through caching in the client where:
mlody3k>  - dm-cache is only responsible to check whether requested data is in the cache device (return
mlody3k> requested data if hit, ENODATA if miss - do not read from origin) - in case of miss, my client
mlody3k> will read data from the origin.
mlody3k>  - dm-cache will write only to the cache device - client will write data to the origin.

So instead, why don't you just have two different mount points, one
being /cache, the other being /slow, and have your app look for data
in /cache first, then pull from /slow.  If you write data, then you
just write it yourself where you want.

dm-cache is more of a block level tool, and you're looking for more of
a file level tool from what I can see.

Probably what you really want is to be able to tune and tweak the
algorithm inside dm-cache to do what you want.  In that case, I don't
have a clue how this would happen unfortunately.

Re: dm-cache + storage client experiment

[Mike Snitzer]

On Tue, Jan 19 2016 at 11:01am -0500,
mlody3k . <mlody3k@gmail.com> wrote:

> Hi dm developers!
> 
> I'm during the experiment with dm-cache and storage client and I would be
> very grateful if some of You will help me with some of my questions :).
> 
> Simply, I would like to implement the write-through caching in the client
> where:
>  - dm-cache is only responsible to check whether requested data is in the
> cache device (return requested data if hit, ENODATA if miss - do not read
> from origin) - in case of miss, my client will read data from the origin.
>  - dm-cache will write only to the cache device - client will write data to
> the origin.
> 
> Easily, I need to start dm-cache in writethrough mode without determining
> the origin device. More specifically, I need to make two changes in dm code:
>  - Bypass the origin device while writing data
>  - Do not remap the result to the origin device in case of read miss.
> 
> So here's my questions:
>  - Do the similar solution exists?
>  - Do I have to change the policy code or maybe all of this things are
> contained in the target code?
>  - Could someone reproduce the IO path in dm-cache code?

I vaguely recall fielding this type of question before...

DM cache doesn't provide this.  And I'm not aware of any modifications
others have done to approximate what you're asking for.

I'm missing why the origin device driver's access isn't the equivalent
of your "client".  If you need some shim for what is allowed through
this client you'd be better off developing a DM target that provides
this client-based access to the data.  And _not_ modifying dm-cache.