Re: [PATCH] Don't initialise new inode generation numbers to zero V2

[Greg Banks <gnb@melbourne.sgi.com>]

Christoph Hellwig wrote:
> On Tue, Apr 22, 2008 at 03:04:48PM +1000, David Chinner wrote:
>   
>>
>> Christoph, care to explain how and why this is a problem to everyone?
>>     
>
> XFS has some heuristics for inode placement and of course for removing
> the inode cluster and re-allocting it.  I have a gut feeling that there
> is a small chance to trigger a re-use via nfs operations.  
Dave's initial patch -- please correct me if I misunderstood it -- kept
a per-AG counter which was used to initialise the generation number of
new inodes.  This counter incremented every time an inode was created in
that AG, i.e. every mknod() mkdir() or creat() bumps the counter for the
appropriate AG. So it served as a per-AG inode generation number, which
given the fixed mapping between AG and inode# means it's just like a
per-inode generation number but sparser.  Thus the only way you could
cause a re-use of an (inode,gen) tuple would be by cycling through
2^32-1 inode creations anywhere in the same AG before destroying and
re-creating the original inode.  That's as good a protection as 32bits
is going to buy.  So if Dave's first patch works the way I think it
works, it should be just fine for NFS' purposes.  Am I missing something?

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.