[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <137929.1597242232@warthog.procyon.org.uk>
Date: Wed, 12 Aug 2020 15:23:52 +0100
From: David Howells <dhowells@...hat.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: dhowells@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>, Karel Zak <kzak@...hat.com>,
Jeff Layton <jlayton@...hat.com>,
Miklos Szeredi <mszeredi@...hat.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Christian Brauner <christian@...uner.io>,
Lennart Poettering <lennart@...ttering.net>,
Linux API <linux-api@...r.kernel.org>,
Ian Kent <raven@...maw.net>,
LSM <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)
Miklos Szeredi <miklos@...redi.hu> wrote:
> The point is that generic operations already exist and no need to add
> new, specialized ones to access metadata.
open and read already exist, yes, but the metadata isn't currently in
convenient inodes and dentries that you can just walk through. So you're
going to end up with a specialised filesystem instead, I suspect. Basically,
it's the same as your do-everything-through-/proc/self/fds/ approach.
And it's going to be heavier. I don't know if you're planning on creating a
superblock each time you do an O_ALT open, but you will end up creating some
inodes, dentries and a file - even before you get to the reading bit.
David
Powered by blists - more mailing lists