[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgSy9ozqC4YfySobH5vZNt9nEyAp2kGL3dW--=4OUmmfw@mail.gmail.com>
Date: Fri, 26 Jan 2024 15:11:55 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
Christian Brauner <brauner@...nel.org>, Ajay Kaher <ajay.kaher@...adcom.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers
On Fri, 26 Jan 2024 at 15:04, Matthew Wilcox <willy@...radead.org> wrote:
>
> Maybe we should take advantage of that historical oddity. All files
> in eventfs have inode number 0, problem solved.
That might not be a horrible idea.
The same way "a directory with st_nlink 1 clearly cannot have a
subdirectory count" (which tools like 'find' know about), maybe it
would be a good idea to use a zero inode number for 'this file doesn't
have an inode number".
Now, presumably no tool knows that, but we could try to aim for that
being some future standard thing.
(And by "standard", I mean a practical one, not some POSIX thing. I
think POSIX just mentions "numberr of hardlinks", and then the whole
"a value of one means that we can't count subdirectories" is just a
practical reality for things like FAT).
Linus
Powered by blists - more mailing lists