public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Dave Chinner <david@fromorbit.com>,
	 Bernd Schubert <bschubert@ddn.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>,  Jan Kara <jack@suse.cz>,
	 Matt Harvey <mharvey@jumptrading.com>,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes
Date: Tue, 18 Feb 2025 11:51:19 +0000	[thread overview]
Message-ID: <87frkb8o94.fsf@igalia.com> (raw)
In-Reply-To: <CAJfpegu51xNUKURj5rKSM5-SYZ6pn-+ZCH0d-g6PZ8vBQYsUSQ@mail.gmail.com> (Miklos Szeredi's message of "Tue, 18 Feb 2025 11:34:53 +0100")

On Tue, Feb 18 2025, Miklos Szeredi wrote:

> On Tue, 18 Feb 2025 at 11:04, Luis Henriques <luis@igalia.com> wrote:
>
>> The problem I'm trying to solve is that, if a filesystem wants to ask the
>> kernel to get rid of all inodes, it has to request the kernel to forget
>> each one, individually.  The specific filesystem I'm looking at is CVMFS,
>> which is a read-only filesystem that needs to be able to update the full
>> set of filesystem objects when a new generation snapshot becomes
>> available.
>
> Yeah, we talked about this use case.  As I remember there was a
> proposal to set an epoch, marking all objects for "revalidate needed",
> which I think is a better solution to the CVMFS problem, than just
> getting rid of unused objects.

OK, so I think I'm missing some context here.  And, obviously, I also miss
some more knowledge on the filesystem itself.  But, if I understand it
correctly, the concept of 'inode' in CVMFS is very loose: when a new
snapshot generation is available (you mentioned 'epoch', which is, I
guess, the same thing) the inodes are all renewed -- the inode numbers
aren't kept between generations/epochs.

Do you have any links for such discussions, or any details on how this
proposal is being implemented?  This would probably be done mostly in
user-space I guess, but it would still need a way to get rid of the unused
inodes from old snapshots, right?  (inodes from old snapshots still in use
would obvious be kept aroud).

Cheers,
-- 
Luís

  reply	other threads:[~2025-02-18 11:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 13:32 [PATCH v6 0/2] fuse: allow notify_inval for all inodes Luis Henriques
2025-02-17 13:32 ` [PATCH v6 1/2] vfs: export invalidate_inodes() Luis Henriques
2025-02-18  0:39   ` Dave Chinner
2025-02-17 13:32 ` [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes Luis Henriques
2025-02-18  0:55   ` Dave Chinner
2025-02-18  9:15     ` Miklos Szeredi
2025-02-18 10:04       ` Luis Henriques
2025-02-18 10:34         ` Miklos Szeredi
2025-02-18 11:51           ` Luis Henriques [this message]
2025-02-18 14:26             ` Miklos Szeredi
2025-02-18 18:11               ` Luis Henriques
2025-02-18 22:05                 ` Dave Chinner
2025-02-19 11:23                   ` Luis Henriques
2025-02-19 15:39                     ` Miklos Szeredi
2025-02-19 16:31                       ` Luis Henriques
2025-02-18 21:29               ` Dave Chinner
2025-02-18 21:44       ` Dave Chinner
2025-02-18  9:07   ` Miklos Szeredi

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=87frkb8o94.fsf@igalia.com \
    --to=luis@igalia.com \
    --cc=brauner@kernel.org \
    --cc=bschubert@ddn.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mharvey@jumptrading.com \
    --cc=miklos@szeredi.hu \
    --cc=viro@zeniv.linux.org.uk \
    /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