public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stuart Rowan <strr-debian@decisionsoft.co.uk>
To: David Chinner <dgc@sgi.com>
Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com
Subject: Re: TAKE 979416 - Don't initialise new inode generation numbers to zero
Date: Wed, 30 Apr 2008 10:23:49 +0100	[thread overview]
Message-ID: <48183AA5.9030804@decisionsoft.co.uk> (raw)
In-Reply-To: <20080429004144.757D658C4C15@chook.melbourne.sgi.com>

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.
> 
> 
> 

  reply	other threads:[~2008-04-30  9:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29  0:41 TAKE 979416 - Don't initialise new inode generation numbers to zero David Chinner
2008-04-30  9:23 ` Stuart Rowan [this message]
2008-04-30 10:22   ` David Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48183AA5.9030804@decisionsoft.co.uk \
    --to=strr-debian@decisionsoft.co.uk \
    --cc=dgc@sgi.com \
    --cc=sgi.bugs.xfs@engr.sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox