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. -- 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
