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:

quoted

On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote:

quoted

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.

quoted

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 ;)

quoted

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.