From: Gionatan Danti <g.danti@assyoma.it>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: lists.linux.dev@frank.fyi, linux-lvm@lists.linux.dev
Subject: Re: add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot
Date: Wed, 17 Jan 2024 23:00:08 +0100 [thread overview]
Message-ID: <498260979ce52ebe20da0c0a36a4342e@assyoma.it> (raw)
In-Reply-To: <5848cefc-bc5e-4f23-8278-d1654607398f@gmail.com>
Il 2024-01-17 12:08 Zdenek Kabelac ha scritto:
> It's also not completely
> true that even 'writethrough' cache cannot have dirty-blocks (aka -
> only present in cache and origin had failed writes).
Hi, really? From dm-cache docs:
"If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean."
So I would not expect to see dirty blocks on write-through cache, unless
the origin device is unable to write at all - which means that removing
the cache device would be no worse that not having it at all in the
first place.
What am I missing?
> But ATM we are not seeing it as some major trouble. Hotspot cache is
> simply not supposed to be randomly removed from your systems - as it
> it's not easy to rebuild.
As a write-through cache should not contain dirty data, using a single
SSD for caching should be OK. I think that if such expendable (and
write-through) SSD fails, one should be able to boot without issues.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
next prev parent reply other threads:[~2024-01-17 22:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 18:19 add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot lists.linux.dev
2024-01-17 11:08 ` Zdenek Kabelac
2024-01-17 22:00 ` Gionatan Danti [this message]
2024-01-18 15:40 ` Zdenek Kabelac
2024-01-18 19:50 ` Gionatan Danti
2024-01-20 20:29 ` lists.linux.dev
[not found] ` <1279983342.522347.1705803666448@mail.yahoo.com>
2024-01-22 10:58 ` 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=498260979ce52ebe20da0c0a36a4342e@assyoma.it \
--to=g.danti@assyoma.it \
--cc=linux-lvm@lists.linux.dev \
--cc=lists.linux.dev@frank.fyi \
--cc=zdenek.kabelac@gmail.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 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.