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

Mark Goodwin
2007-08-31T04:31:58Z

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