On Tue, Jan 03, 2012 at 04:43:48PM -0600, Bill Kendall wrote: > On 01/03/2012 03:31 PM, Dave Chinner wrote: > >On Tue, Jan 03, 2012 at 03:15:34PM -0600, Bill Kendall wrote: > >>On 12/26/2011 02:18 PM, David Brown wrote: > >>>http://oss.sgi.com/bugzilla/show_bug.cgi?id=915 > >>> > >>>I've had this happen again. It appears to be the case if between > >>>incremental dumps, a file is deleted and a directory is created that > >>>gets the same inode number. The restore leaves a file in place of the > >>>directory. If the new directory has any contents, xfsrestore prints a > >>>warning, and doesn't restore the subdirectory contents. > >>> > >>>Given the sparseness of inodes, this doesn't seem to occur all that > >>>frequently, but I do have a couple of backups that exhibit the > >>>behavior. If no one has any ideas, I'll start digging through > >>>xfsrestore to see if I can figure out what is happening. > >> > >>I haven't looked at the relevant code, but it sounds like the inode > >>generation number would also have to be the same in order for this > >>to happen. Two inodes from separate backups are only considered to > >>be the same file or directory if the inode number and the lower 12 > >>bits of the inode generation number are the same. > > > >Why does dump only use the lower twelve bits? The on-disk generation > >number is 32 bits and we use all of it (by way of random numbers) to > >distinguish between different inode generations. That sounds like > >something that needs to be fixed.... > > I don't know the history there, but it dates back to when the generation > number was not randomly initialized. So an inode had to be reused 4,096 > times for a collision to occur. That's kind of what I thought. But even so, with the way XFS reuses inodes (especially for short term temporary files), those 12 bits can eaily be burnt through in under a second.... > With the current scheme (initially > random, then incremented) there would be cases where a collision > happens more frequently. I agree, it should be changed. Is that difficult to do? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
