From: lists.linux.dev@frank.fyi
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: linux-lvm@lists.linux.dev
Subject: Re: add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot
Date: Sat, 20 Jan 2024 20:29:40 +0000 [thread overview]
Message-ID: <jtvhdzv3dcpbqlbatkhkzruedmc3tfa3vv6h54pvw4dayrnj6s@v2u63oe75k5z> (raw)
In-Reply-To: <3d1e18f3-a79f-4e0d-8b6c-7f10e5c8debf@gmail.com>
On Thu, Jan 18, 2024 at 04:40:47PM +0100, Zdenek Kabelac wrote:
> Cache can contain blocks that are still being 'synchronized' to the cache
> origin. So while the 'writing' process doesn't get ACK for writes - the
> cache
> may have valid blocks that are 'dirty' in terms of being synchronized to
> origin device.
>
> And while this is usually not a problem when system works properly,
> it's getting into weird 'state machine' model when i.e. origin device has
> errors - which might be even 'transient' with all the variety of storage
> types and raid arrays with integrity and self-healing and so on...
>
> So while it's usually not a problem for a laptop with 2 disks, the world is
> more complex...
Ehm, but wouldn't anything other than discarding that block from the cache and using whatever is on the backing storage introduce unpredictable errors?
As like you already said it was never ACKed, so the software that tried to write it never expected it to be written.
Why exactly are we allowed to use the data from the write-through cache to modify the data on the backing storage in such cases?
I.E. Why can we safely consider it as valid data?
> metadata - so if there is again some 'reboot' and PV with cache appears back
> - it will not interfere with the system (aka providing some historical
> cached blocks, so just like mirrored leg needs some care...)
Same here, why do we have to consider these blocks at all and can't discard them? We know when a drive re-appears, so we could just not use it without validation, or in the case the volatile flag I suggested would be used, just wipe it and start over...
After all I don't know anyone that designs their storage systems with the assumption that the write-through cache has to be redundant.
Even more, I know enough people in data center environments that reuse their "failing but still kinda good" SSDs and NVMEs for write-through caches using the assumption that them failing at most impacts read performance but not data security.
Is there some common missconception at play? Or what exaclty am I missing here?
Sincerely,
Klaus Frank
next prev parent reply other threads:[~2024-01-20 20:35 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
2024-01-18 15:40 ` Zdenek Kabelac
2024-01-18 19:50 ` Gionatan Danti
2024-01-20 20:29 ` lists.linux.dev [this message]
[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=jtvhdzv3dcpbqlbatkhkzruedmc3tfa3vv6h54pvw4dayrnj6s@v2u63oe75k5z \
--to=lists.linux.dev@frank.fyi \
--cc=linux-lvm@lists.linux.dev \
--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.