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. The simplest would be to generate a 'random' number (get_random_bytes). Slightly better would be to generate a random number at boot time and use that, incrementing it each time it is used to set the generation number for an inode. Even better would be store store that 'next generation number' in the superblock so there would be even less risk of the 'random' generation producing repeats. This is what ext3 does. It doesn't dynamically allocate inodes, but it doesn't want to pay the cost of reading an old inode from storage just to see what the generation number is. So it has a number in the superblock which is incremented on each inode allocation and is used as the generation number. Certainly anything would be better than always using the same number. NeilBrown -- 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
