From: Su Yue <glass.su@suse.com>
To: linux-lvm@lists.linux.dev
Cc: Heming Zhao <heming.zhao@suse.com>,
Anthony Iliopoulos <ailiopoulos@suse.com>,
Lidong Zhong <lidong.zhong@suse.com>,
martin.wilck@suse.com
Subject: [Question] why not flush device cache at _vg_commit_raw
Date: Mon, 22 Jan 2024 19:22:09 +0800 [thread overview]
Message-ID: <A4568496-76AE-479C-8B80-F27D7EBC1DEB@suse.com> (raw)
Hi lvm folks,
Recently We received a report about the device cache issue after vgchange —deltag.
What confuses me is that lvm never calls fsync on block devices even at the end of commit phase.
IIRC, it’s common operations for userspace tools to call fsync/O_SYNC/O_DSYNC while writing
critical data. Yes, lvm2 opens devices with O_DIRECT if they support , but O_DIRECT doesn't
provide data was persistent to storage when write returns. The data can still be in the device cache,
If power failure happens in the timing, such critical metadata/data like vg metadata could be lost.
Is there any particular reason not to flush data cache at VG commit time?
Thanks
—
Su
next reply other threads:[~2024-01-22 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 11:22 Su Yue [this message]
2024-01-22 12:48 ` [Question] why not flush device cache at _vg_commit_raw Zdenek Kabelac
2024-01-22 13:46 ` Anthony Iliopoulos
2024-01-22 14:52 ` Zdenek Kabelac
2024-01-22 15:26 ` Ilia Zykov
2024-01-23 1:54 ` Su Yue
2024-01-23 8:15 ` Martin Wilck
2024-01-22 16:01 ` Anthony Iliopoulos
2024-01-23 16:42 ` Demi Marie Obenour
2024-01-23 17:50 ` Zdenek Kabelac
2024-01-24 11:58 ` Anthony Iliopoulos
2024-01-24 12:35 ` Zdenek Kabelac
2024-01-24 13:13 ` Anthony Iliopoulos
2024-01-24 23:17 ` Heming Zhao
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=A4568496-76AE-479C-8B80-F27D7EBC1DEB@suse.com \
--to=glass.su@suse.com \
--cc=ailiopoulos@suse.com \
--cc=heming.zhao@suse.com \
--cc=lidong.zhong@suse.com \
--cc=linux-lvm@lists.linux.dev \
--cc=martin.wilck@suse.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 read-only IMAP folder(s) and NNTP newsgroup(s).