32  * The basics of filesystem summary counter checking are that we iterate the
35  * Then we compare what we computed against the in-core counters.
38  * While we /could/ freeze the filesystem and scramble around the AGs counting
39  * the free blocks, in practice we prefer not do that for a scan because
40  * freezing is costly.  To get around this, we added a per-cpu counter of the
41  * delalloc reservations so that we can rotor around the AGs relatively
42  * quickly, and we allow the counts to be slightly off because we're not taking
43  * any locks while we do this.
45  * So the first thing we do is warm up the buffer cache in the setup routine by
48  * structures as quickly as it can.  We snapshot the percpu counters before and
56  * we'll allow ourselves to be off by at least this (arbitrary) amount.
67  * 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
367 	/* Bail out if the values we compute are totally nonsense. */  in xchk_fscount_aggregate_agcounts()
374 	 * If ifree > icount then we probably had some perturbation in the  in xchk_fscount_aggregate_agcounts()
375 	 * counters while we were calculating things.  We'll try a few times  in xchk_fscount_aggregate_agcounts()
447  * Part 2: Comparing filesystem summary counters.  All we have to do here is
448  * sum the percpu counters and compare them to what we've observed.
454  * We neither locked nor froze anything in the filesystem while aggregating the
456  * could have changed.  We know the @old_value of the summation of the counter
457  * before the aggregation, and we re-sum the counter now.  If the expected
458  * value falls between the two summations, we're ok.
460  * Otherwise, we /might/ have a problem.  If the change in the summations is
461  * more than we want to tolerate, the filesystem is probably busy and we should
464  * If we're repairing then we require an exact match.
487 	/* We require exact matches when repair is running. */  in xchk_fscount_within_range()
528 	 * values here, and we should only flag that as a corruption if we  in xchk_fscounters()
572 	 * Compare the in-core counters with whatever we counted.  If the fs is  in xchk_fscounters()
573 	 * frozen, we treat the discrepancy as a corruption because the freeze  in xchk_fscounters()
574 	 * should have stabilized the counter values.  Otherwise, we need  in xchk_fscounters()