Re: [PATCH] log replay should not overwrite newer ondisk inodes

[Lachlan McIlroy <lachlan@xxxxxxx>]

Timothy Shimmin wrote:
> Timothy Shimmin wrote:
> > > >   But I'm not sure this is an error...
> > > >   Hmmmm...I'm a bit confused.
> > > >   So you are _almost_ combining an error check with a flushiter check?
> > > >   If one buffer is an inode magic# and the other isn't then we
> > > >   have an error right - and could report it - but we are not doing 
> > > > that here.
> > > Not exactly.  If what's on disk is not an inode but the log item is
> > > then that could be because we haven't written the inode to disk yet
> > > and we need to perform recovery.
> > Yeah, I was thinking about that afterward.
> > The item's format which gives the blk# for the buf to read could
> > be a block which hasn't been used for an inode yet.
> Well, if what's on disk is not an inode but some other data
> and it happens to have the inode magic# which is remotely possible,
> then we are making a bad assumption.
> i.e. if we're not sure what the block/buffer should be, then testing the
> MAGIC# isn't a guarantee it's an inode then.
> Well not for the freeing of inode clusters case I would assume.
> Or am I missing something?
I don't think you're missing anything!

You're right though - a magic number check is no guarantee.  On the same
vein, adding a generation number check isn't much better.