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.
>
>
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.