From: Heming Zhao <heming.zhao@suse.com>
To: Anthony Iliopoulos <ailiop@suse.com>,
Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>,
Su Yue <glass.su@suse.com>,
linux-lvm@lists.linux.dev, Lidong Zhong <lidong.zhong@suse.com>,
martin.wilck@suse.com
Subject: Re: [Question] why not flush device cache at _vg_commit_raw
Date: Thu, 25 Jan 2024 07:17:51 +0800 [thread overview]
Message-ID: <ce7d5d40-027a-4119-b6ad-9ce7d04aa81a@suse.com> (raw)
In-Reply-To: <ZbEM7Ri0_30DYHh6@technoir>
On 1/24/24 21:13, Anthony Iliopoulos wrote:
> On Wed, Jan 24, 2024 at 01:35:49PM +0100, Zdenek Kabelac wrote:
>> I guess our dev_flush() function is mostly handling all those cases properly
>> with the use of ioctl(BLKFLSBUF).
>
> This ioctl by itself will only flush the page cache and not device
> caches, but it is indeed followed by a fsync on the blockdev which is
> basically the only way for userspace to trigger a device cache flush
> when operating directly on a block device.
>
>> The only problem is - it's usage somehow vanished - and even in the past
>> it's been basically used only for non-direct usage so likely still not
>> correct.
>
> Indeed, the device cache flushing is required for data integrity
> irrespective of the io mode (unless O_DSYNC/RWF_DSYNC), direct-io only
> obviates the need for flushing the page cache.
>
In my view, vg_commit() is a good place to call dev_flush(). This could
only affect (important) metadata IOs, make all write IOs to persistent
storage ASAP.
Thanks,
Heming
prev parent reply other threads:[~2024-01-24 23:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 11:22 [Question] why not flush device cache at _vg_commit_raw Su Yue
2024-01-22 12:48 ` 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 [this message]
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=ce7d5d40-027a-4119-b6ad-9ce7d04aa81a@suse.com \
--to=heming.zhao@suse.com \
--cc=ailiop@suse.com \
--cc=demi@invisiblethingslab.com \
--cc=glass.su@suse.com \
--cc=lidong.zhong@suse.com \
--cc=linux-lvm@lists.linux.dev \
--cc=martin.wilck@suse.com \
--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 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).