Re: dm-cache issue

[Teodor Milkov <tm@del.bg>]

On 14.11.2016 17:34, Zdenek Kabelac wrote:
> Dne 14.11.2016 v 16:02 Alexander Pashaliyski napsal(a):
>> The server is booting for hours, because of IO load. It seems is 
>> triggered a flush from SSD disk (that is used for a cache device) to 
>> the raid controllers (they are with slow SATA disks).
>> I have 10 cached logical volumes in *writethrough mode*, each with 2T 
>> of data over 2 raid controllers. I use a single SSD disk for the cache.
>> The backup system is with lvm2-2.02.164-1 & kernel 4.4.30.
>>
>> Do you have any ideas why such flush is triggered? In writethrough 
>> cache mode
>> we shouldn't have dirty blocks in the cache.
>>
>
> Have you ensured there was proper shutdown ?
> Cache needs to be properly deactivated - if it's just turned off,
> all metadata are marked dirty.
>
> Zdenek

Hi,

I'm seeing the same behavior described by Alexander. Even if we assume 
something is wrong with my shutdown scripts, still how could dm-cache 
ever be dirty in writethrough mode? What about the case where server 
crashes for whatever reason (kernel bug, power outage, operator error 
etc.)? Waiting several hours, or for sufficiently large cache even days 
for the system to come back up is not practical.

I found this 2013 conversation, where Heinz Mauelshagen <heinzm redhat 
com> states that "in writethrough mode the cache will always be coherent 
after a crash": 
https://www.redhat.com/archives/dm-devel/2013-July/msg00117.html

I'm thinking for a way to --uncache and recreate cache devices on every 
boot, which should be safe in writethrough mode and takes reasonable, 
and more importantly – constant amount of time.

Best regards,
Teodor Milkov

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