xfs
[Top] [All Lists]

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

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes
From: Mark Goodwin <markgw@xxxxxxx>
Date: Fri, 31 Aug 2007 14:01:37 +1000
Cc: Timothy Shimmin <tes@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <46D77B79.3040104@xxxxxxx>
Organization: SGI Engineering
References: <46D6279F.40601@xxxxxxx> <46D6480F.4040307@xxxxxxx> <46D64CAD.6050705@xxxxxxx> <46D67FE6.20205@xxxxxxx> <46D68510.1020404@xxxxxxx> <46D77B79.3040104@xxxxxxx>
Reply-to: markgw@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.13 (Windows/20070809)


Lachlan McIlroy wrote:
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.

unlink will have to invalidate the on-disk inode magic number? Or only
when the whole cluster is free'd?

-- Mark


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