----- Original Message ----- > Hi Bob, > > On 22/01/15 20:41, Bob Peterson wrote: > > Hi, > > > > This patch changes the old block_map structure for fsck.gfs2 to the > > simpler bitmap structure so that we have a 1:1 correspondence. This > > was done to reduce memory requirements of fsck.gfs2. > > I'm curious as to whether we're losing any useful information here. I > see an extra bread() for BLKST_USED blocks in check_data, is that the > main performance compromise, and how severe is it? > > Cheers, > Andy
Hi, That's exactly where things get a bit sticky. It used to keep track of the various GFS2_METATYPE_* block types. For the most part, dinodes were straightforward because we only needed to distinguish between directories and non-directories. Free space is pretty straightforward too, with only a few corner cases where things were marked a "bad" type. Unlinked also wasn't a big problem. The problem comes with blocks marked "Data." In GFS1, "data" blocks were data blocks. In GFS2, a data block could be data or metadata. In some cases we don't care because the height will tell us if it's real data. But things get sticky when we need to distinguish between different types of non-dinode metadata in fsck. For example, what if a dinode has "indirect blocks" that are not really indirect blocks, but say, an extended attribute block? The old fsck could distinguish between them pretty easily because of their unique types. Going by just the bitmap alone is ambiguous, so sometimes we need to know more details, especially in cases where we have a block that's referenced multiple times: it's much more likely that one of the references is for the wrong type, and in that case, we do the extra read. This shouldn't impact performance, except for duplicate references (which is rare) and needs to be done. There are probably cases where fsck is now making assumptions about the previously processed block type for indirect blocks, so in that respect, the information is lost. However, I've tried to minimize the risk, and rigorous testing has shown that it works in many very difficult situations. You can tell my testing has been good, since I've posted so many bug fix patches recently that I've uncovered. :) In that respect, this new fsck is better than the previous. Still, there may very well be cases where the lost information causes an unforeseen problem. I'm not sure we can do anything about that but test it thoroughly. Maybe I'll try to dummy up some potential problems (like the one I gave above with indirect versus extended attribute) to see how well it does. I suppose I could try to dummy up every permutation. That is likely to uncover even more problems, most of which already exist in today's fsck. Regards, Bob Peterson Red Hat File Systems
