Yes they matter, but not as much as they used to.
There's a lot of historical doco around that describes these things. How apposite that doco is depends from what operating system you have and how you administer your system.
For example: As M. Dickey says, if you still run the
dump command, then the information in the
freq column very much does matter, as it tells
dump what to do. Conversely, if you are in the same boat as the answerer at https://superuser.com/a/247527/38062 , then the information in the
dump column is probably not used by anything in your system.
The way that operating systems work in this area has changed significantly, and the relevance of these columns has changed.
Historically, one ran
fsck in a boot-time script, with options that told it to read
/etc/fstab and process all entries in pass-number order. And there's copious doco instructing you to pick specific values for pass numbers in the
passno column, as you are alluding to in the question.
That doco is out of date. The world has changed.
systemd operating systems
On systemd operating systems,
fsck doesn't have that responsibility any more.
The native configuration format for systemd is the unit, which can be amongst other things a service unit or a mount unit. systemd's service management proper operates solely in terms of those. Your
/etc/fstab database is converted into mount and service units by a program named
systemd-fstab-generator. This program is a generator, a type of ancillary utility whose job is to create unit files on the fly. It generates
.mount units that mount the volumes and
.service units that run
systemd-fsck (which chains to
fsck after setting up a client-server connection to a server that displays progress information) against individual volumes.
/etc/fstab is effectively a source file and it is not the native control/configuration system.
The operation of
systemd-fstab-generator completely ignores the
freq column of
/etc/fstab. And it only cares whether the
passno column is zero or non-zero. If the latter, it generates references that cause the invocation of a
email@example.com service to run
fsck. If the former, it does not. So there's no difference if you choose 2, 1, or indeed 17035.
The nosh toolset also converts
/etc/fstab to native form, which in the nosh case is a suite of service bundles. Its program for doing this is
convert-fstab-services. This can be run explicitly, or one can make use of the auto-conversion system in
/etc/system-control/convert/ to update service bundles whenever
freq column is ignored. (Don't be confused by the
dump@device service bundles that it creates. That's to do with BSD crash dumping, not to do with filesystem backup via the
dump command.) And again the only thing that matters about the
passno column is that it is greater than zero, which is what causes a
fsck@directory service bundle to be created and joined up to the
mount@directory service bundle.
The upshot of both the nosh and the systemd way of doing things is that instead of a single
fsck being run in a mode that scans
/etc/fstab and decides what to do, at one single point in the system bootstrap (or two, as in the case of the BSD
rc.d system which tries to distinguish "background" from "foreground" volumes), running
fsck is triggered by starting the individual "mount" services.
The filesystems that aren't mounted at bootstrap (because they are marked
noauto) thus do not have their
fscks run at bootstrap.
fsck that does nothing anyway
passno matters inasmuch as it controls the generation of nosh service bundles or system service units that (indirectly) run
fsck against individual volumes; sometimes that
fsck is effectively a no-operation. Some filesystem formats simply don't have
fsck tools that can operate in the "unattended preen" mode than one needs for these bootstrap-time/mount-time
This is the case for at least:
For such filesystem types, the practical effect of
passno is thus nil. Set it to zero, no
fsck service will run. Set it to non-zero, the
fsck service that runs invokes a program that does nothing.