Messages in this thread | | | Date | Sun, 8 May 2016 22:46:17 -0400 | From | "J. Bruce Fields" <> | Subject | Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available |
| |
On Mon, May 09, 2016 at 11:45:43AM +1000, Dave Chinner wrote: > [ OT, but I'll reply anyway :P ] > > On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > > In the latest XFS filesystem format, we randomise the generation > > > value during every inode allocation to make it hard to guess the > > > handle of adjacent inodes from an existing ino+gen pair, or even > > > from life time to life time of the same inode. > > > > The one thing I wonder about is whether that increases the probability > > of a filehandle collision (where you accidentally generate the same > > filehandle for two different files). > > Not possible - inode number is still different between the two > files. i.e. ino+gen makes the handle unique, not gen. > > > If the generation number is a 32-bit counter per inode number (is that > > actually the way filesystems work?), then it takes 2^32 reuses of the > > inode number to hit the same filehandle. > > 4 billion unlink/create operations that hit the same inode number > are going to take some time. I suspect someone will notice the load > generated by an attmept to brute force this sort of thing ;) > > > If you choose it randomly then > > you expect a collision after about 2^16 reuses. > > I'm pretty sure that a random search will need to, on average, > search half the keyspace before a match is found (i.e. 2^31 > attempts, not 2^16).
Yeah, but I was wondering whether you could somehow get into the situation where clients between then are caching N distinct filehandles with the same inode number. Then a collision becomes likely around 2^16, by the usual birthday paradox rule-of-thumb.
Uh, but now that I think of it that's irrelevant. At most one of those filehandles actually refers to a still-existing file. Any attempt to use the other 2^16-1 should return -ESTALE. So collisions among that set don't matter, it's only collisions involving the existing file that are interesting. So, nevermind, I can't see a practical way to hit a problem here....
--b.
| |