Re: [PATCH] eventfs: Have inodes have unique inode numbers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers
- From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
- Date: Fri, 26 Jan 2024 23:04:34 +0000
- Cc: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>, Steven Rostedt <rostedt@xxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Linux Trace Devel <linux-trace-devel@xxxxxxxxxxxxxxx>, Masami Hiramatsu <mhiramat@xxxxxxxxxx>, Christian Brauner <brauner@xxxxxxxxxx>, Ajay Kaher <ajay.kaher@xxxxxxxxxxxx>, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
- In-reply-to: <CAHk-=wiF0ATuuxJhwgm707izS=5q4xBUSh+06U2VwFEJj0FNRw@mail.gmail.com>
- References: <20240126150209.367ff402@gandalf.local.home> <CAHk-=wgZEHwFRgp2Q8_-OtpCtobbuFPBmPTZ68qN3MitU-ub=Q@mail.gmail.com> <20240126162626.31d90da9@gandalf.local.home> <CAHk-=wj8WygQNgoHerp-aKyCwFxHeyKMguQszVKyJfi-=Yfadw@mail.gmail.com> <CAHk-=whNfNti-mn6vhL-v-WZnn0i7ZAbwSf_wNULJeyanhPOgg@mail.gmail.com> <8547159a-0b28-4d75-af02-47fc450785fa@efficios.com> <ZbQzXfqA5vK5JXZS@casper.infradead.org> <CAHk-=wiF0ATuuxJhwgm707izS=5q4xBUSh+06U2VwFEJj0FNRw@mail.gmail.com>
On Fri, Jan 26, 2024 at 02:48:45PM -0800, Linus Torvalds wrote:
> On Fri, 26 Jan 2024 at 14:34, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jan 26, 2024 at 05:14:12PM -0500, Mathieu Desnoyers wrote:
> > > I would suggest this straightforward solution to this:
> > >
> > > a) define a EVENTFS_MAX_INODES (e.g. 4096 * 8),
> > >
> > > b) keep track of inode allocation in a bitmap (within a single page),
> > >
> > > c) disallow allocating more than "EVENTFS_MAX_INODES" in eventfs.
> >
> > ... reinventing the IDA?
>
> Guysm, this is a random number that is *so* interesting that I
> seriously think we shouldn't have it at all.
>
> End result: nobody should care. Even the general VFS layer doesn't care.
>
> It literally avoids inode number zero, not because it would be a bad
> inode number, but simply because of some random historical oddity.
>
> In fact, I don't think we even have a reason for it. We have a commit
> 2adc376c5519 ("vfs: avoid creation of inode number 0 in get_next_ino")
> and that one calls out glibc for not deleting them. That makes no
> sense to me, but whatever.
Maybe we should take advantage of that historical oddity. All files
in eventfs have inode number 0, problem solved.
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]