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. But note how the generic function does *not* try to make them unique, for example. They are just "unique enough". The generic function *does* care about being scalable in an SMP environment. To a disturbing degree. Oh well. Linus