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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox