All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Josef 'Jeff' Sipek" <jeffpc-PM1Ls4bqFqUFEYicpp4bmg@public.gmane.org>
To: NeilBrown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	xfs@oss.sgi.com,
	Adam Schrotenboer <adam-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>,
	Jesper Juhl <jesper.juhl@gmail.com>,
	Trond Myklebust <trond.myklebust@netapp.com>,
	lkml@vger.kernel.org, linux-nfs@vger.kernel.org,
	Thomas Daniel <tdaniel-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>,
	Frederic Revenu <frevenu-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>,
	Jeff Doan <jdoan-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [opensuse] nfs_update_inode: inode X mode changed, Y to Z
Date: Tue, 25 Mar 2008 17:24:25 -0400	[thread overview]
Message-ID: <20080325212425.GA20257@josefsipek.net> (raw)
In-Reply-To: <32953.192.168.1.70.1206477121.squirrel-eq65iwfR9nKIECXXMXunQA@public.gmane.org>

On Wed, Mar 26, 2008 at 07:32:01AM +1100, NeilBrown wrote:
> I suggest taking it up with the XFS developers...
> 
> Dear XFS developers.
>  Adam (and Jesper, though that was some time ago) was having problems
> with an XFS filesystem that was exported via NFS.  The client would
> occasionally report the message given in the subject line.
> Examining the NFS code suggested that the most likely explanation
> was that the generation number used in the file handle was the same
> every time that the inode number was re-used.
> 
> Examining the XFS code suggested that when the 'ikeep' mount option was
> used, the generation number be explicitly incremented for each
> re-use, while without 'ikeep', no evidence of setting the generation
> number could be found.  Maybe it defaults to zero.
> 
> Experimental evidence suggests that setting 'ikeep' removes the symptom.
> 
> Question:  Is is possible that without 'ikeep', XFS does not even try
> to provide unique generation numbers?  If this is the case, could it
> please be fixed.  If it is not the case, please help me find the code
> responsible.

Unless you specify the "ikeep" mount option, XFS will remove unused inode
clusters.  The newly freed blocks can be then used to store data or possibly
a new inode cluster.  If the blocks get reused for inodes, you'll end up
with inodes whose generation numbers regressed. (inode number = f(block
number))

Using the "ikeep" mount option causes to _never_ free empty inode clusters.
This means that if you create many files and then unlink them, you'll end up
with many unused inodes that are still allocated (and taking up disk space)
but free to be used by the next creat(2)/mkdir(2)/etc..

This "problem" is inherent to any file system which dynamically allocates
inodes.

Josef 'Jeff' Sipek.

-- 
Linux, n.:
  Generous programmers from around the world all join forces to help
  you shoot yourself in the foot for free. 

WARNING: multiple messages have this Message-ID (diff)
From: "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
To: NeilBrown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	xfs@oss.sgi.com, Adam Schrotenboer <adam@m2000.com>,
	Jesper Juhl <jesper.juhl@gmail.com>,
	Trond Myklebust <trond.myklebust@netapp.com>,
	lkml@vger.kernel.org, linux-nfs@vger.kernel.org,
	Thomas Daniel <tdaniel@m2000.com>,
	Frederic Revenu <frevenu@m2000.com>, Jeff Doan <jdoan@m2000.com>
Subject: Re: [opensuse] nfs_update_inode: inode X mode changed, Y to Z
Date: Tue, 25 Mar 2008 17:24:25 -0400	[thread overview]
Message-ID: <20080325212425.GA20257@josefsipek.net> (raw)
In-Reply-To: <32953.192.168.1.70.1206477121.squirrel@neil.brown.name>

On Wed, Mar 26, 2008 at 07:32:01AM +1100, NeilBrown wrote:
> I suggest taking it up with the XFS developers...
> 
> Dear XFS developers.
>  Adam (and Jesper, though that was some time ago) was having problems
> with an XFS filesystem that was exported via NFS.  The client would
> occasionally report the message given in the subject line.
> Examining the NFS code suggested that the most likely explanation
> was that the generation number used in the file handle was the same
> every time that the inode number was re-used.
> 
> Examining the XFS code suggested that when the 'ikeep' mount option was
> used, the generation number be explicitly incremented for each
> re-use, while without 'ikeep', no evidence of setting the generation
> number could be found.  Maybe it defaults to zero.
> 
> Experimental evidence suggests that setting 'ikeep' removes the symptom.
> 
> Question:  Is is possible that without 'ikeep', XFS does not even try
> to provide unique generation numbers?  If this is the case, could it
> please be fixed.  If it is not the case, please help me find the code
> responsible.

Unless you specify the "ikeep" mount option, XFS will remove unused inode
clusters.  The newly freed blocks can be then used to store data or possibly
a new inode cluster.  If the blocks get reused for inodes, you'll end up
with inodes whose generation numbers regressed. (inode number = f(block
number))

Using the "ikeep" mount option causes to _never_ free empty inode clusters.
This means that if you create many files and then unlink them, you'll end up
with many unused inodes that are still allocated (and taking up disk space)
but free to be used by the next creat(2)/mkdir(2)/etc..

This "problem" is inherent to any file system which dynamically allocates
inodes.

Josef 'Jeff' Sipek.

-- 
Linux, n.:
  Generous programmers from around the world all join forces to help
  you shoot yourself in the foot for free. 

  parent reply	other threads:[~2008-03-25 21:24 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05 20:52 [opensuse] nfs_update_inode: inode X mode changed, Y to Z Adam Schrotenboer
     [not found] ` <47CF0829.4020502-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
2008-03-05 21:27   ` Trond Myklebust
     [not found]     ` <1204752463.5035.34.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-03-05 21:49       ` Adam Schrotenboer
2008-03-06  3:12         ` Neil Brown
     [not found]           ` <18383.24847.381754.517731-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-03-06  3:19             ` Adam Schrotenboer
2008-03-07  4:38               ` Neil Brown
     [not found]                 ` <18384.50909.866848.966192-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-03-07  5:55                   ` Adam Schrotenboer
2008-03-07  5:55                     ` Adam Schrotenboer
     [not found]                     ` <47D0D8B5.6050403-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
2008-03-12 17:55                       ` Adam Schrotenboer
2008-03-12 17:55                         ` Adam Schrotenboer
     [not found]                         ` <47D818FB.8080302-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
2008-03-12 18:08                           ` Trond Myklebust
2008-03-12 18:08                             ` Trond Myklebust
     [not found]                             ` <1205345284.9419.8.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-03-12 18:16                               ` Adam Schrotenboer
2008-03-12 18:16                                 ` Adam Schrotenboer
2008-03-12 22:13                   ` Jesper Juhl
     [not found]                     ` <9a8748490803121513w285cd45rb6b26a3d842cac1b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-03-12 22:15                       ` J. Bruce Fields
2008-03-12 22:16                         ` Jesper Juhl
2008-03-14  4:58                           ` Neil Brown
     [not found]                             ` <18394.1501.991087.80264-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-03-14 21:21                               ` Jesper Juhl
2008-03-14 21:36                               ` Adam Schrotenboer
     [not found]                                 ` <47DAEFD0.9020407-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
2008-03-25 16:59                                   ` Adam Schrotenboer
     [not found]                                     ` <47E92F8E.7030504-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org>
2008-03-25 19:09                                       ` J. Bruce Fields
2008-03-25 20:32                                         ` NeilBrown
2008-03-25 20:32                                           ` NeilBrown
     [not found]                                           ` <32953.192.168.1.70.1206477121.squirrel-eq65iwfR9nKIECXXMXunQA@public.gmane.org>
2008-03-25 21:24                                             ` Josef 'Jeff' Sipek [this message]
2008-03-25 21:24                                               ` Josef 'Jeff' Sipek
     [not found]                                               ` <20080325212425.GA20257-PM1Ls4bqFqUFEYicpp4bmg@public.gmane.org>
2008-03-25 21:38                                                 ` NeilBrown
2008-03-25 21:38                                                   ` NeilBrown
     [not found]                                                   ` <34178.192.168.1.70.1206481102.squirrel-eq65iwfR9nKIECXXMXunQA@public.gmane.org>
2008-03-25 22:13                                                     ` Josef 'Jeff' Sipek
2008-03-25 22:13                                                       ` Josef 'Jeff' Sipek
     [not found]                                                       ` <20080325221321.GC20257-PM1Ls4bqFqUFEYicpp4bmg@public.gmane.org>
2008-03-25 23:09                                                         ` NeilBrown
2008-03-25 23:09                                                           ` NeilBrown
2008-03-26  3:37                                                         ` David Chinner
2008-03-26  3:37                                                           ` David Chinner
2008-03-26  5:02                                                           ` David Chinner
2008-03-26  5:02                                                             ` David Chinner
2008-04-17 19:37                                                             ` Adam Schrotenboer
2008-03-26  3:27                                                     ` Timothy Shimmin
2008-03-26  3:27                                                       ` Timothy Shimmin
     [not found] <47C5EC81.6080004@m2000.com>
     [not found] ` <47C71EC6.3050702@m2000.com>
     [not found]   ` <3AD71C5E-B45A-4BDB-8C94-73D62256BEBF@astro.wisc.edu>
2008-03-12 18:06     ` Adam Schrotenboer

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=20080325212425.GA20257@josefsipek.net \
    --to=jeffpc-pm1ls4bqfqufeyicpp4bmg@public.gmane.org \
    --cc=adam-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
    --cc=bfields@fieldses.org \
    --cc=frevenu-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
    --cc=jdoan-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lkml@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tdaniel-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
    --cc=trond.myklebust@netapp.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.