From: Ryan Launchbury <ryan@magenta.tv>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: LVM general discussion and development <linux-lvm@redhat.com>,
Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [linux-lvm] Unable to un-cache logical volume when chunk size is over 1MiB
Date: Sun, 24 Jun 2018 20:18:49 +0100 [thread overview]
Message-ID: <CAG+REr=gFS_3YMo_6s5K32w=ibntEshE7VBOy-7Vt2c7Psi_kQ@mail.gmail.com> (raw)
In-Reply-To: <c351a57bdcf219c04b315aa02b6207ea@assyoma.it>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
Hi Zdenek and Gionatan,
Thanks for your reply's.
Something else of note: on systems which are unable to flush the cache,
data is still being written to the origin LV somehow, because there is
200TB of data in the LV, but the cache is only 1.8TB, so somehow it is
working. However when running any commands to flush the cache, or uncache,
it seems unable to.
What sort of admin work needs to be done/can be done to force the flush and
remove the cache?
I've tried the cleaner policy, however, it doesn't seem to be flushing
anything.
In testing, forcibly removing the cache, via editing the LVM config file
has caused extensive XFS filesystem corruption, even when backing up the
metadata first and restoring after the cache device is missing. Any advice
on how to safely uncache the volume would be massively appreciated.
Please let me know if you need any more logs or data.
Best regards,
Ryan
On Sat, Jun 23, 2018 at 11:09 AM Gionatan Danti <g.danti@assyoma.it> wrote:
> Il 22-06-2018 22:07 Zdenek Kabelac ha scritto:
> > When cache will experience write error - it will become invalidate and
> > will
> > need to be dropped - but this thing is not automated ATM - so admin
> > works is needed to handle this task.
>
> So, if a writethrough cache experience write errors but the
> administrator is not able to immediately intervene to drop the cache,
> what problem can arise? Stale reads? Slow performance?
>
> What about cache *read* error? Is the read simply redirected to the
> underlying slow/main volume?
>
> Thanks.
>
> --
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.danti@assyoma.it - info@assyoma.it
> GPG public key ID: FF5F32A8
>
[-- Attachment #2: Type: text/html, Size: 2351 bytes --]
next prev parent reply other threads:[~2018-06-24 19:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 9:18 [linux-lvm] Unable to un-cache logical volume when chunk size is over 1MiB Ryan Launchbury
2018-06-20 10:15 ` Zdenek Kabelac
2018-06-20 11:10 ` Ryan Launchbury
2018-06-22 18:13 ` Gionatan Danti
2018-06-22 19:22 ` Ryan Launchbury
2018-06-22 20:07 ` Zdenek Kabelac
2018-06-23 10:09 ` Gionatan Danti
2018-06-24 19:18 ` Ryan Launchbury [this message]
2018-06-25 17:19 ` Gionatan Danti
2018-06-25 17:20 ` Ryan Launchbury
2018-06-25 17:40 ` Gionatan Danti
2018-07-18 14:25 ` Ryan Launchbury
2018-07-18 14:58 ` Douglas Paul
2019-01-21 20:19 ` Zdenek Kabelac
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='CAG+REr=gFS_3YMo_6s5K32w=ibntEshE7VBOy-7Vt2c7Psi_kQ@mail.gmail.com' \
--to=ryan@magenta.tv \
--cc=g.danti@assyoma.it \
--cc=linux-lvm@redhat.com \
--cc=zkabelac@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).