dm-cache: dirty state of blocks in writethrough mode

dm-cache: dirty state of blocks in writethrough mode

[Vijarnia, Anil]

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

Hello,

In Documentation/cache.txt, section 'Updating on-disk metadata' mentions that "If the system crashes all cache blocks will be assumed dirty when restarted".

I am assuming that the above line is relevant for writeback mode only, and in writethrough mode the cache will always be coherent after a crash.

Can someone confirm/reject this assumption?



Thanks










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

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

Re: dm-cache: dirty state of blocks in writethrough mode

[Heinz Mauelshagen]

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

On 07/23/2013 08:44 AM, Vijarnia, Anil wrote:
> Hello,
> In Documentation/cache.txt, section 'Updating on-disk metadata' mentions that "If the system crashes all cache blocks will be assumed dirty when restarted".
> I am assuming that the above line is relevant for writeback mode only, and in writethrough mode the cache will always be coherent after a crash.
> Can someone confirm/reject this assumption?

That's correct

Reason being that the cache never holds any dirty pages in writethrough 
mode.

-- lvmguy

>   
> Thanks
>   
>   
>   
>   
>
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel


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

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

Re: dm-cache: dirty state of blocks in writethrough mode

[Kumar amit mehta]

On Tue, Jul 23, 2013 at 03:26:08PM +0200, Heinz Mauelshagen wrote:
> On 07/23/2013 08:44 AM, Vijarnia, Anil wrote:
> >Hello,
> >In Documentation/cache.txt, section 'Updating on-disk metadata' mentions that "If the system crashes all cache blocks will be assumed dirty when restarted".
> >I am assuming that the above line is relevant for writeback mode only, and in writethrough mode the cache will always be coherent after a crash.
> >Can someone confirm/reject this assumption?
> 
> That's correct
> 
> Reason being that the cache never holds any dirty pages in
> writethrough mode.

I'm new to storage and would like to know the linux implementation of
writeback policy of disk cache. In case these disk caches are stored in
volatile RAM and we hit system crash, so that cache is gone, but somehow
we have to flush those pending writes to the backend storage, once the
system comes up. How this is achieved in general, Is it through some
kind of metadata that is maintained in a separate area of the disk or it
relies on the file system's journalling capability?

!!amit

Re: dm-cache: dirty state of blocks in writethrough mode

[Kumar amit mehta]

On Wed, Jul 24, 2013 at 07:05:59PM +0200, Heinz Mauelshagen wrote:
> dm-cache maintains it's own metadata keeping track of any cached
> blocks properties
> such as a block being dirty in case of writeback.
> 
> If any write in writeback mode hits a cache block, the cache metadata will
> reflect that dirty state before the write's being reported to the
> application.
> 
> After a crashed system rebooted, that information is available to flush a
> dirty block out on eviction.

Ahh, so It is the metadata device. Maybe overkill, but is it
possible to keep redundant copies of this metadata, like user space
utilities such as LVM2 does?

!!amit

Re: dm-cache: dirty state of blocks in writethrough mode

[Heinz Mauelshagen]

On 07/24/2013 12:24 PM, Kumar amit mehta wrote:
> On Tue, Jul 23, 2013 at 03:26:08PM +0200, Heinz Mauelshagen wrote:
>> On 07/23/2013 08:44 AM, Vijarnia, Anil wrote:
>>> Hello,
>>> In Documentation/cache.txt, section 'Updating on-disk metadata' mentions that "If the system crashes all cache blocks will be assumed dirty when restarted".
>>> I am assuming that the above line is relevant for writeback mode only, and in writethrough mode the cache will always be coherent after a crash.
>>> Can someone confirm/reject this assumption?
>> That's correct
>>
>> Reason being that the cache never holds any dirty pages in
>> writethrough mode.
> I'm new to storage and would like to know the linux implementation of
> writeback policy of disk cache. In case these disk caches are stored in
> volatile RAM and we hit system crash, so that cache is gone, but somehow
> we have to flush those pending writes to the backend storage, once the
> system comes up. How this is achieved in general, Is it through some
> kind of metadata that is maintained in a separate area of the disk or it
> relies on the file system's journalling capability?

dm-cache maintains it's own metadata keeping track of any cached blocks 
properties
such as a block being dirty in case of writeback.

If any write in writeback mode hits a cache block, the cache metadata will
reflect that dirty state before the write's being reported to the 
application.

After a crashed system rebooted, that information is available to flush a
dirty block out on eviction.

Heinz

>
> !!amit

Re: dm-cache: dirty state of blocks in writethrough mode

[Heinz Mauelshagen]

On 07/24/2013 03:02 PM, Kumar amit mehta wrote:
> On Wed, Jul 24, 2013 at 07:05:59PM +0200, Heinz Mauelshagen wrote:
>> dm-cache maintains it's own metadata keeping track of any cached
>> blocks properties
>> such as a block being dirty in case of writeback.
>>
>> If any write in writeback mode hits a cache block, the cache metadata will
>> reflect that dirty state before the write's being reported to the
>> application.
>>
>> After a crashed system rebooted, that information is available to flush a
>> dirty block out on eviction.
> Ahh, so It is the metadata device. Maybe overkill, but is it
> possible to keep redundant copies of this metadata, like user space
> utilities such as LVM2 does?

You can set up a mirrored metadata device to be resilient against SSD 
failures.

Plus you can take metadata snapshots at arbitrary points in time;
see the targets kernel documentation in thin-provisioning.txt for this
and the recent thin_dump support metadata snapshots  in the rawhide
device-mapper-persistent-data package.

Either is subject to future LVM2 support and isn't supported as yet.

Heinz

>
> !!amit

Re: dm-cache: dirty state of blocks in writethrough mode

[Kumar amit mehta]

On Thu, Jul 25, 2013 at 12:45:31PM +0200, Heinz Mauelshagen wrote:
> You can set up a mirrored metadata device to be resilient against
> SSD failures.

Okay

> Plus you can take metadata snapshots at arbitrary points in time;
> see the targets kernel documentation in thin-provisioning.txt for this
> and the recent thin_dump support metadata snapshots  in the rawhide
> device-mapper-persistent-data package.
>

So these feature is already upstream and also in fedora 20, but not in 
Red Hat 6.4 yet ?

> Either is subject to future LVM2 support and isn't supported as yet.

So, if LVM2 doesn't support it as of now, Any idea if EVMS or any other
volume Managers consume these features?

!!amit

Re: dm-cache: dirty state of blocks in writethrough mode

[Heinz Mauelshagen]

On 07/26/2013 04:45 AM, Kumar amit mehta wrote:
> On Thu, Jul 25, 2013 at 12:45:31PM +0200, Heinz Mauelshagen wrote:
>> You can set up a mirrored metadata device to be resilient against
>> SSD failures.
> Okay
>
>> Plus you can take metadata snapshots at arbitrary points in time;
>> see the targets kernel documentation in thin-provisioning.txt for this
>> and the recent thin_dump support metadata snapshots  in the rawhide
>> device-mapper-persistent-data package.
>>
> So these feature is already upstream and also in fedora 20, but not in
> Red Hat 6.4 yet ?

No, it's planned for RHEL7.

>
>> Either is subject to future LVM2 support and isn't supported as yet.
> So, if LVM2 doesn't support it as of now, Any idea if EVMS or any other
> volume Managers consume these features?

None that I'm aware of.

Use dmsetup for early testing.

We'll support it in LVM2 later in the year.

Heinz

>
> !!amit
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel