linux-kernel - Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frkb8o94.fsf@igalia.com>
Date: Tue, 18 Feb 2025 11:51:19 +0000
From: Luis Henriques <luis@...lia.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Dave Chinner <david@...morbit.com>,  Bernd Schubert <bschubert@....com>,
  Alexander Viro <viro@...iv.linux.org.uk>,  Christian Brauner
 <brauner@...nel.org>,  Jan Kara <jack@...e.cz>,  Matt Harvey
 <mharvey@...ptrading.com>,  linux-fsdevel@...r.kernel.org,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for
 all inodes

On Tue, Feb 18 2025, Miklos Szeredi wrote:

> On Tue, 18 Feb 2025 at 11:04, Luis Henriques <luis@...lia.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