[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiPx0UJ6Q1X=azwz32xrSeKnTJcH8enySwuuwnGKkHoPA@mail.gmail.com>
Date: Wed, 12 Aug 2020 11:18:23 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Howells <dhowells@...hat.com>
Cc: Miklos Szeredi <miklos@...redi.hu>,
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)
On Tue, Aug 11, 2020 at 5:05 PM David Howells <dhowells@...hat.com> wrote:
>
> Well, the start of it was my proposal of an fsinfo() system call.
Ugh. Ok, it's that thing.
This all seems *WAY* over-designed - both your fsinfo and Miklos' version.
What's wrong with fstatfs()? All the extra magic metadata seems to not
really be anything people really care about.
What people are actually asking for seems to be some unique mount ID,
and we have 16 bytes of spare information in 'struct statfs64'.
All the other fancy fsinfo stuff seems to be "just because", and like
complete overdesign.
Let's not add system calls just because we can.
Linus
Powered by blists - more mailing lists