[dm-devel] lvmcache volume gets 100% dirty blocks after power loss regardless of previous state

[Pellegrino Prevete]

Hi everyone,

I have set up a lvmcache lv (on archlinux) using as fast disk the emmc
of my laptop and as slow one a microsd card inserted in the integrated
slot, following the man instructions.

Its dimensions are 10gb and 41gb respectively and I am using this lv
as /home partition.
I used default options, excluding having set 'writeback' as
cachemode.
 
After I transferred the data (30gb) I noticed that cache used
blocks and cache dirty blocks were now both above 99.94%.

When after some time I tried to turn off the laptop, the shutdown
procedure, being unable to complete the lv unmounting in the time
frame assigned to the task (4m), simply skipped it and the computer was
forced to shut down.

On next boots I found that when not booting in recovery mode the drive
could not be mounted most of the times.

In general, if I shutted down the system before the dirty blocks
percentage went to 0%, it would become 100% all over again at the next
boot.

So I decided to change cachemode to 'writethrough' and wait for the
cache dirty blocks to be zero to see if doing so would solve the
problem.

To my surprise, it took over 24 hours.

With 0% dirty blocks, the system was obviously booting fine.
Also, having previously switched to 'writethrough', I expected in
general not to have dirty blocks at all anymore. 

Today I forgot to attach the power cable and the laptop shutted
down because of low power.

After this, booting has become difficult again and dirty blocks are
again 99%.

Also, judging from iostat output writes on the sd card (happening in
the background I believe) are really really slow.

I wanted to know:
- if this behaviour is normal,
- if there is a way to avoid it apart from clean shutting downs at 0%
  dirty blocks,
- why do I have dirty blocks in 'writethrough' mode,
- if there is a way to empty the cache without erasing the whole volume,
- if there is a way to trigger the cleaning process directly with an
  'high' priority.

Cheers,
Pellegrino
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20190712/1a03cc43/attachment.sig>