All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	 linux-mm@kvack.org, linux-btrfs@vger.kernel.org,
	linux-block@vger.kernel.org,
	 Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
	Christoph Hellwig <hch@infradead.org>,
	 adrianvovk@gmail.com
Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Thu, 18 Jan 2024 15:09:42 +0100	[thread overview]
Message-ID: <20240118-wieweit-windschatten-19cfa8111b45@brauner> (raw)
In-Reply-To: <ZahUBkqYad0Lb3/V@dread.disaster.area>

> > The fact that after a block layer initiated freeze - again mostly a
> > device mapper problem - one may or may not be able to successfully read
> > from the filesystem is annoying. Of course one can't write, that will
> > hang one immediately. But if one still has some data in the page cache
> > one can still dump the contents of that file. That's at least odd
> > behavior from a users POV even if for us it's cleary why that's the
> > case.
> 
> A frozen filesystem doesn't prevent read operations from occurring.

Yes, that's what I was saying. I'm not disputing that.

> 
> > And a freeze does do a sync_filesystem() and a sync_blockdev() to flush
> > out any dirty data for that specific filesystem.
> 
> Yes, it's required to do that - the whole point of freezing a
> filesystem is to bring the filesystem into a *consistent physical
> state on persistent storage* and to hold it in that state until it
> is thawed.
> 
> > So it would be fitting
> > to give users an api that allows them to also drop the page cache
> > contents.
> 
> Not as part of a freeze operation.

Yes, that's why I'd like to have a separate e.g., flag for fadvise.

> > For some use-cases like the Gnome use-case one wants to do a freeze and
> > drop everything that one can from the page cache for that specific
> > filesystem.
> 
> So they have to do an extra system call between FS_IOC_FREEZE and
> FS_IOC_THAW. What's the problem with that? What are you trying to
> optimise by colliding cache purging with FS_IOC_FREEZE?
> 
> If the user/application/infrastructure already has to iterate all
> the mounted filesystems to freeze them, then it's trivial for them
> to add a cache purging step to that infrastructure for the storage
> configurations that might need it. I just don't see why this needs
> to be part of a block device freeze operation, especially as the
> "purge caches on this filesystem" operation has potential use cases
> outside of the luksSuspend context....

Ah, I'm sorry I think we're accidently talking past each other... I'm
_not_ trying to tie block layer freezing and cache purging. I'm trying
to expose something like:

posix_fadvise(fs_fd, [...], POSIX_FADV_FS_DONTNEED/DROP);

The Gnome people could then do:

cryptsetup luksSuspend
posix_fadvise(fs_fd, [...], POSIX_FADV_FS_DONTNEED/DROP);

as two separate operations.

Because the dropping the caches step is useful to other users as well;
completely independent of the block layer freeze that I used to
motivate this.

  reply	other threads:[~2024-01-18 14:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16 10:50 [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Christian Brauner
2024-01-16 11:45 ` Jan Kara
2024-01-17 12:53   ` Christian Brauner
2024-01-17 14:35     ` Jan Kara
2024-01-17 14:52       ` Matthew Wilcox
2024-01-17 20:51         ` Phillip Susi
2024-01-17 20:58           ` Matthew Wilcox
2024-01-18 14:26         ` Christian Brauner
2024-01-30  0:13         ` Adrian Vovk
2024-02-15 13:57           ` Jan Kara
2024-02-15 19:46             ` Adrian Vovk
2024-02-15 23:17               ` Dave Chinner
2024-02-16  1:14                 ` Adrian Vovk
2024-02-16 20:38                   ` init_on_alloc digression: " John Hubbard
2024-02-16 21:11                     ` Adrian Vovk
2024-02-16 21:19                       ` John Hubbard
2024-01-16 15:25 ` James Bottomley
2024-01-16 15:40   ` Matthew Wilcox
2024-01-16 15:54     ` James Bottomley
2024-01-16 20:56 ` Dave Chinner
2024-01-17  6:17   ` Theodore Ts'o
2024-01-30  1:14     ` Adrian Vovk
2024-01-17 13:19   ` Christian Brauner
2024-01-17 22:26     ` Dave Chinner
2024-01-18 14:09       ` Christian Brauner [this message]
2024-02-05 17:39     ` Russell Haley
2024-02-17  4:04 ` Kent Overstreet

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=20240118-wieweit-windschatten-19cfa8111b45@brauner \
    --to=brauner@kernel.org \
    --cc=adrianvovk@gmail.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    /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.