[Cluster-devel] [gfs2-utils PATCH 24/47] fsck.gfs2: Rework the "undo" functions

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Thu, 2013-05-16 at 09:49 -0400, Bob Peterson wrote:
> ----- Original Message -----
> | Hi,
> | 
> | This sounds to me like we are doing things in the wrong order. We
> | shouldn't need to undo things that have been done, otherwise we'll just
> | land up in a tangle,
> | 
> | Steve.
> 
> Hi,
> 
> Pass1's job is to traverse the metadata tree of every dinode, marking
> which blocks are metadata, which are data, which are ext. attributes, etc.
> With its current design, it runs through that tree once (for each dinode),
> marking the blocks as it goes in its blockmap. If it encounters damage it
> can't recover from, it has to "undo" those designations, otherwise you
> end up in situations where a severely damaged dinode causes a lot of
> collateral damage because it references blocks that are in use by a
> newer, healthier dinode with valid references.
> 
> The alternative is to run through each dinode's metadata tree twice:
> Once to determine its general health, and a second time to remember the
> blocks it used in the blockmap. This obviously would be a lot slower.
> The slowness would affect every dinode, healthy or damaged, whereas the
> current method only takes extra time for damaged dinodes.
> 
> This ability to "undo" blockmap designations is not new to fsck.gfs2.
> It's been doing that for many releases. Recent patches just restructured
> it a bit to make better decisions and only affect pass1.
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems
> 

Yes, but the undo side of things worries me... it is very easy to get
tied in knots doing that. The question is what is "damage it can't
recover from"? this is a bit vague and doesn't really explain what is
going on here.

I don't yet understand why we'd need to run through each inodes metadata
tree more than once in this case,

Steve.