xfs
[Top] [All Lists]

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

To: Timothy Shimmin <tes@xxxxxxx>
Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Fri, 31 Aug 2007 12:22:49 +1000
Cc: xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <46D68510.1020404@xxxxxxx>
References: <46D6279F.40601@xxxxxxx> <46D6480F.4040307@xxxxxxx> <46D64CAD.6050705@xxxxxxx> <46D67FE6.20205@xxxxxxx> <46D68510.1020404@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.4 (X11/20070604)
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.


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