> [some of this Dave and I discussed on IRC, so I'll summarize for > everyone else here...] > > For this initial v0 iteration of the rmap repair code, yes, we have to > freeze the fs and iterate everything. However, unless your computer and > storage are particularly untrustworthy, rmapbt reconstruction should be > a very infrequent thing. Now that we have a FREEZE_OK flag, userspace > has to opt-in to slow repairs, and presumably it could choose instead to > unmount and run xfs_repair if that's too dear or there are too many > broken AGs, etc. More on that later. > > In the long run I don't see a need to freeze the filesystem to scan > every inode for bmbt entries in the damaged AG. In fact, we can improve > the performance of all the AG repair functions in general with the > scheme I'm about to outline: > > Create a "shut down this AG" primitive. Once set, block and inode > allocation routines will bypass this AG. Unlinked inodes are moved to > the unlinked list to avoid touching as much of the AGI as we practically > can. Unmapped/freed blocks can be moved to a hidden inode (in another > AG) to be freed later. Growfs operation in that AG can be rejected. > Does it mean that new block allocation requestsvfor inodes already existing in the frozen AG will block until the AG is thawed, or these block allocations will be redirected to another AG? I'm just asking because in either case, we should document it well. The repair case is certainly (or should be) a rare case, but if there is any heavy workload going on on the frozen AG, and we redirect it to another AG, it can end up heavily fragmenting the files on the frozen AG. So, I wonder if any operation to the AG under repair should actually be blocked too? Cheers -- Carlos -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
