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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
