Re: xfsrestore: incorrect restore if file becomes a dir

[Bill Kendall <wkendall@sgi.com>]

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. With the current scheme (initially
random, then incremented) there would be cases where a collision
happens more frequently. I agree, it should be changed.

Bill

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs