TAKE 979416 - Don't initialise new inode generation numbers to zero

TAKE 979416 - Don't initialise new inode generation numbers to zero

[David Chinner]

Don't initialise new inode generation numbers to zero

When we allocation new inode chunks, we initialise the generation
numbers to zero. This works fine until we delete a chunk and then
reallocate it, resulting in the same inode numbers but with a
reset generation count. This can result in inode/generation
pairs of different inodes occurring relatively close together.

Given that the inode/gen pair makes up the "unique" portion of
an NFS filehandle on XFS, this can result in file handles cached
on clients being seen on the wire from the server but refer to
a different file. This causes .... issues for NFS clients.

Hence we need a unique generation number initialisation for
each inode to prevent reuse of a small portion of the generation
number space. Use a random number to initialise the generation
number so we don't need to keep any new state on disk whilst
making the new number difficult to guess from previous allocations.

Date:  Tue Apr 29 10:41:26 AEST 2008
Workarea:  chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs
Inspected by:  hch@infradead.org

The following file(s) were checked into:
  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb


Modid:  xfs-linux-melb:xfs-kern:31001a
fs/xfs/xfs_ialloc.c - 1.199 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h
	- use random32() to initialise the generation in newly allocated
	  inodes to prevent short term reuse of inode,gen pairs which
	  can cause ESTALE problems for NFS clients.

Re: TAKE 979416 - Don't initialise new inode generation numbers to zero

[Stuart Rowan]

Is this liable to affect the stable releases, 2.6.24.y and 2.6.25.y? If so, 
is it appropriate for forwarding to the stable team?

I only ask because we have a heavily used NFS /home-directory server that 
uses XFS for the underlying store.

Cheers,
Stu.

David Chinner wrote, on 29/04/08 01:41:
> Don't initialise new inode generation numbers to zero
> 
> When we allocation new inode chunks, we initialise the generation
> numbers to zero. This works fine until we delete a chunk and then
> reallocate it, resulting in the same inode numbers but with a
> reset generation count. This can result in inode/generation
> pairs of different inodes occurring relatively close together.
> 
> Given that the inode/gen pair makes up the "unique" portion of
> an NFS filehandle on XFS, this can result in file handles cached
> on clients being seen on the wire from the server but refer to
> a different file. This causes .... issues for NFS clients.
> 
> Hence we need a unique generation number initialisation for
> each inode to prevent reuse of a small portion of the generation
> number space. Use a random number to initialise the generation
> number so we don't need to keep any new state on disk whilst
> making the new number difficult to guess from previous allocations.
> 
> Date:  Tue Apr 29 10:41:26 AEST 2008
> Workarea:  chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs
> Inspected by:  hch@infradead.org
> 
> The following file(s) were checked into:
>   longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb
> 
> 
> Modid:  xfs-linux-melb:xfs-kern:31001a
> fs/xfs/xfs_ialloc.c - 1.199 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_ialloc.c.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h
> 	- use random32() to initialise the generation in newly allocated
> 	  inodes to prevent short term reuse of inode,gen pairs which
> 	  can cause ESTALE problems for NFS clients.
> 
> 
> 

Re: TAKE 979416 - Don't initialise new inode generation numbers to zero

[David Chinner]

On Wed, Apr 30, 2008 at 10:23:49AM +0100, Stuart Rowan wrote:
> Is this liable to affect the stable releases, 2.6.24.y and 2.6.25.y? If so, 
> is it appropriate for forwarding to the stable team?

Yes, and I will do so once we've got .26-rc1 out the door.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group