As the subject says, I have a Raspbian system (Buster, and this happened with the prior Raspbian version too) that runs a full fsck on one particular volume every time it boots. And this only happens for one particular volume, not all the disks - they finish immediately because they are also clean. (the volume in question is not the root filesystem, it's one that's used for ancillary storage, not any system function.)
I've been searching on this problem for months, but the finds tend to be cases where they want to cause a forced-fsck to happen. It's hard to find any posts about this particular, and opposite, problem.
I could (and have, temporarily) set the fsck flag in /etc/fstab to '0' to skip it, but would like to have it still run enough at boot to notice the clean filesystem and not run a full check.
Things I've tried so far:
Physically moving the volume (it's in a standalone USB disk case) to another Raspbian system of the same version, I observed that host does things as it should: It verifies the filesystem, noting it as clean at boot, and thus does not run a complete check.
I've looked at the usual superblock fields (tune2fs -l) for last-check date and mount-count, and set the flags to prevent the per-mount-count and date-based auto-checks, but the system still does one every time.
If I manually fsck the volume, fsck.ext4 reports it as clean immediately.
A manual complete fsck -f of the unmounted volume ran cleanly, but did not solve the problem.
But if I reboot, systemd-fsckd launches an fsck that runs through the whole thing, taking about 20-30 minutes (it's a 1.8TB volume, about 25% full).
I've also tried completely deleting the volume and the disk's partition table and starting from scratch, new partition table and new volume, new filesystem (parted, mkfs.ext4, etc). No change in the problem.
The fsck process, when running at boot-time, shows it was invoked with the usual flags (-y -C4), neither of which should cause it to always run a full check on a 'clean' volume.
What else could be causing this?