Le vendredi 08 octobre 2010 Ã 09:48 -0400, Christoph Hellwig a Ãcrit :
> On Fri, Oct 08, 2010 at 12:20:19PM +0200, Eric Dumazet wrote:
> > If iunique() was scalable, sockets could use it, so that we can have
> > hard guarantee two sockets on machine dont have same inum.
> >
> > A reasonable compromise here is to use a simple and scalable allocator,
> > and take the risk two sockets have same inum.
> >
> > While it might break some applications playing fstats() games, on
> > sockets, current schem is vastly faster.
> >
> > I worked with machines with millions of opened socket concurrently,
> > iunique() was not an option, and application didnt care of possible inum
> > clash.
>
> The current version of iuniqueue is indeed rather suboptimal. As is
> the pure counter approach. I think the right way to deal with it
> is to use an idr allocator. This means the filesystem needs to
> explicitly free the inode number when the inode is gone, but that
> just makes the usage more clear. Together with the lazy assignment
> scheme for synthetic filesystems that should give us both speed and
> correctness.
>
On 32bit arches, inum for sockets/pipes could be pretty fast
unsigned u32 rnd_val __read_mostly; /* seeded at boot time */
unsigned u32 get_inum(struct inode *ino, size_t size)
{
return rnd_val ^ ((long)ino + random32() % size);
}
(Ie , use fact that an inode is a kernel object, with a given address
and a given size, two inodes cannot overlap)
I have no idea how scalable is an idr allocator, but it probably uses
one big lock.
Maybe finally generate 64bit inum on 64bit arches...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
