All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Iliopoulos <ailiop@suse.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: Su Yue <glass.su@suse.com>,
	linux-lvm@lists.linux.dev, Heming Zhao <heming.zhao@suse.com>,
	Lidong Zhong <lidong.zhong@suse.com>,
	martin.wilck@suse.com
Subject: Re: [Question] why not flush device cache at _vg_commit_raw
Date: Mon, 22 Jan 2024 14:46:13 +0100	[thread overview]
Message-ID: <Za5xpeEStkITRMtc@technoir> (raw)
In-Reply-To: <eb604d09-a713-4d61-a155-8e289cc5328a@gmail.com>

On Mon, Jan 22, 2024 at 01:48:41PM +0100, Zdenek Kabelac wrote:
> Dne 22. 01. 24 v 12:22 Su Yue napsal(a):
> > 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?
> > 
> 
> Hi
> 
> It seems the call to 'dev_flush()' function got somehow lost over the time
> of conversion to async aio usage - I'll investigate.
> 
> On the other hand the chance here of losing any data this way would be
> really really very specific to some oddly behaving device.

There's no guarantee that data will be persisted to storage without
explicitly flushing the device data cache. Those are usually volatile
write-back caches, so the data aren't really protected against power
loss without fsyncing the blockdev.

Regards,
Anthony

  reply	other threads:[~2024-01-22 13:46 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 [this message]
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=Za5xpeEStkITRMtc@technoir \
    --to=ailiop@suse.com \
    --cc=glass.su@suse.com \
    --cc=heming.zhao@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 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.