From: Timothy Shimmin <tes@sgi.com>
To: NeilBrown <neilb@suse.de>
Cc: "Josef 'Jeff' Sipek"
<jeffpc-PM1Ls4bqFqUFEYicpp4bmg@public.gmane.org>,
"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: Wed, 26 Mar 2008 14:27:26 +1100 [thread overview]
Message-ID: <47E9C29E.6090703@sgi.com> (raw)
In-Reply-To: <34178.192.168.1.70.1206481102.squirrel-eq65iwfR9nKIECXXMXunQA@public.gmane.org>
Hi Neil,
NeilBrown wrote:
> On Wed, March 26, 2008 8:24 am, Josef 'Jeff' Sipek wrote:
>
>> 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.
>
> Yes, I understand all that.
>
> However you still need to do something about the generation number. It
> must be set to something.
>
> When you allocate an inode that doesn't currently exist on the device,
> you obviously cannot increment the old value and use that.
> However you can do a lot better than always using 0.
>
Yes, this is a known problem.
We came across it in about August last year I believe in the context of
DMF as it wants to keep persistent file handles with gen#s in them:
SGI bug:
969192: Default mount option "noikeep" makes the inode generation number non-persistent
I vaguely remember at the time that a number of different schemes were
tossed around but in the end we just turned off the ikeep
for DMAPI mounted filesystems.
I thought we had a bug open to do a real fix but can't see
it at the moment. Will look into it and discuss with our group.
Cheers,
--Tim
WARNING: multiple messages have this Message-ID (diff)
From: Timothy Shimmin <tes@sgi.com>
To: NeilBrown <neilb@suse.de>
Cc: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>,
"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: Wed, 26 Mar 2008 14:27:26 +1100 [thread overview]
Message-ID: <47E9C29E.6090703@sgi.com> (raw)
In-Reply-To: <34178.192.168.1.70.1206481102.squirrel@neil.brown.name>
Hi Neil,
NeilBrown wrote:
> On Wed, March 26, 2008 8:24 am, Josef 'Jeff' Sipek wrote:
>
>> 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.
>
> Yes, I understand all that.
>
> However you still need to do something about the generation number. It
> must be set to something.
>
> When you allocate an inode that doesn't currently exist on the device,
> you obviously cannot increment the old value and use that.
> However you can do a lot better than always using 0.
>
Yes, this is a known problem.
We came across it in about August last year I believe in the context of
DMF as it wants to keep persistent file handles with gen#s in them:
SGI bug:
969192: Default mount option "noikeep" makes the inode generation number non-persistent
I vaguely remember at the time that a number of different schemes were
tossed around but in the end we just turned off the ikeep
for DMAPI mounted filesystems.
I thought we had a bug open to do a real fix but can't see
it at the moment. Will look into it and discuss with our group.
Cheers,
--Tim
next prev parent reply other threads:[~2008-03-26 3:27 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
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 [this message]
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=47E9C29E.6090703@sgi.com \
--to=tes@sgi.com \
--cc=adam-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
--cc=bfields@fieldses.org \
--cc=frevenu-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
--cc=jdoan-PMR2DCmmWYEAvxtiuMwx3w@public.gmane.org \
--cc=jeffpc-PM1Ls4bqFqUFEYicpp4bmg@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.