[Top] [All Lists]

Re: xfsrestore: incorrect restore if file becomes a dir

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: xfsrestore: incorrect restore if file becomes a dir
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 4 Jan 2012 10:16:04 +1100
Cc: David Brown <davidb@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4F0384A4.6000505@xxxxxxx>
References: <20111226201856.GA3909@xxxxxxxxxx> <4F036FF6.2080501@xxxxxxx> <20120103213147.GS23662@dastard> <4F0384A4.6000505@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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?


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>