From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: Teodor Milkov <tm@del.bg>, dm-devel@redhat.com
Subject: Re: dm-cache issue
Date: Wed, 16 Nov 2016 10:24:58 +0100 [thread overview]
Message-ID: <f01aaf8d-1f12-1a6f-5560-5cb6927a1b62@gmail.com> (raw)
In-Reply-To: <55289e1d-5a24-73a5-4ccf-026c2640334d@del.bg>
Dne 15.11.2016 v 13:38 Teodor Milkov napsal(a):
> 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.
My first 'guess' in this reported case is - the disk I/O traffic seen is
related to the 'reload' of cached chunks from disk back to cache.
This will happen in the case, there has been unclean cache shutdown.
However what is unclean is - why it slows down boot by hours.
Is the cache too big??
Regards
Zdenek
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2016-11-16 9:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 15:02 dm-cache issue Alexander Pashaliyski
2016-11-14 15:34 ` Zdenek Kabelac
2016-11-14 16:05 ` Alexander Pashaliyski
2016-11-15 12:38 ` Teodor Milkov
2016-11-16 9:24 ` Zdenek Kabelac [this message]
2016-11-16 13:45 ` Teodor Milkov
2016-11-16 14:06 ` Zdenek Kabelac
2016-11-19 17:07 ` Teodor Milkov
2016-12-02 19:49 ` Teodor Milkov
2016-11-15 19:57 ` John Stoffel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f01aaf8d-1f12-1a6f-5560-5cb6927a1b62@gmail.com \
--to=zdenek.kabelac@gmail.com \
--cc=dm-devel@redhat.com \
--cc=tm@del.bg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.