----- 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
