31  * The basics of filesystem summary counter checking are that we iterate the
34  * Then we compare what we computed against the in-core counters.
37  * While we /could/ freeze the filesystem and scramble around the AGs counting
38  * the free blocks, in practice we prefer not do that for a scan because
39  * freezing is costly.  To get around this, we added a per-cpu counter of the
40  * delalloc reservations so that we can rotor around the AGs relatively
41  * quickly, and we allow the counts to be slightly off because we're not taking
42  * any locks while we do this.
44  * So the first thing we do is warm up the buffer cache in the setup routine by
47  * structures as quickly as it can.  We snapshot the percpu counters before and
55  * we'll allow ourselves to be off by at least this (arbitrary) amount.
66  * This function runs during the setup phase /before/ we start checking any
137 	/* This should always succeed, we have a kernel freeze */  in xchk_fsthaw()
144  * We couldn't stabilize the filesystem long enough to sample all the variables
146  * We need to disable all writer threads, which means taking the first two
149  * more to prevent other callers from unfreezing the filesystem while we run.
204 	 * If the AGF doesn't track btreeblks, we have to lock the AGF to count  in xchk_setup_fscounters()
219 	/* We must get the incore counters set up before we can proceed. */  in xchk_setup_fscounters()
225 	 * Pause all writer activity in the filesystem while we're scrubbing to  in xchk_setup_fscounters()
229 	 * If we're repairing, we need to prevent any other thread from  in xchk_setup_fscounters()
230 	 * changing the global fs summary counters while we're repairing them.  in xchk_setup_fscounters()
244  * Part 1: Collecting filesystem summary counts.  For each AG, we add its
368 	/* Bail out if the values we compute are totally nonsense. */  in xchk_fscount_aggregate_agcounts()
375 	 * If ifree > icount then we probably had some perturbation in the  in xchk_fscount_aggregate_agcounts()
376 	 * counters while we were calculating things.  We'll try a few times  in xchk_fscount_aggregate_agcounts()
446  * Part 2: Comparing filesystem summary counters.  All we have to do here is
447  * sum the percpu counters and compare them to what we've observed.
453  * We neither locked nor froze anything in the filesystem while aggregating the
455  * could have changed.  We know the @old_value of the summation of the counter
456  * before the aggregation, and we re-sum the counter now.  If the expected
457  * value falls between the two summations, we're ok.
459  * Otherwise, we /might/ have a problem.  If the change in the summations is
460  * more than we want to tolerate, the filesystem is probably busy and we should
463  * If we're repairing then we require an exact match.
486 	/* We require exact matches when repair is running. */  in xchk_fscount_within_range()
527 	 * values here, and we should only flag that as a corruption if we  in xchk_fscounters()
571 	 * Compare the in-core counters with whatever we counted.  If the fs is  in xchk_fscounters()
572 	 * frozen, we treat the discrepancy as a corruption because the freeze  in xchk_fscounters()
573 	 * should have stabilized the counter values.  Otherwise, we need  in xchk_fscounters()