fstab integration

[aerusso]

Generate a tracked, updateable section in /etc/fstab for zfs filesystems

Description

A contrib script fstab-generator is implemented that creates a trackable section in /etc/fstab (or another user-specified file) with fstab syntax reflecting the zfs mount and canmount parameters.

Motivation and Context

While #4943 implements a per-pool granular import, the user will still "need to add an entry like this in fstab:

rpool/home /home zfs rw,defaults,x-systemd.requires=zpool@rpool.service

This script performs precisely that mechanical task, allowing for filesystem dependencies to be correctly identified, and mounted in time to guarantee their availability. A monolithic import of all zfs filesystems is not required to have system files on native zfs mountpoints.

Moreover, by including this information in /etc/fstab, tools can fail appropriately if essential mountpoints are unavailable. This helps address the common annoyance where zfs fails to mount an important system directory, files then get placed on the zfs mountpoint, and then zfs will fail to mount on the subsequent boot (because overlay=off) even though the underlying problem was corrected.

Why not a systemd-generator?

Besides the obvious lack of integration for users without systemd, other tools may rely on /etc/fstab to determine what filesystems are present on a system. This approach immediately achieves integration with those tools--e.g., for analogous dependency tracking for other init systems that may develop in the future. Additionally, systemd generators may change syntax in the future, but they will have to remain compatible with /etc/fstab.

How Has This Been Tested?

I'm running with the output of this script on a machine that has several /var/ directories, and /tmp with purely zfs mountpoints.

RFC

This is a work in progress.

1. Should this be converted to fstab-generator.in, and use %sbindir%, etc?
2. Should this name be changed? Should this be installed elsewhere?
3. How could/should this be integrated with the rest of the tools?
4. Is there some reason mount -ozfsutil is ill-advised for zfs filesystems?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[aerusso]

@kpande Good point: as it stands this is only useful for systemd. I've added and enabled options that are useful for systemd by default. Also, I'm definitely not suggesting this get run by default or anything like that---just have it available on people's systems.

This patch is actually useful without #4943: the proper mount ordering can be discovered if you are mounting zfs on top of other (non-root) filesystems (bind mounts, etc.), which was the actual underlying motivation.

[rlaager]

Given that this is only useful for systemd, it seems better to focus on building a "proper" systemd generator. I'm not proposing a definition for "proper" at this time.

[aerusso]

@rlaager I agree. I considered two options for this integration: a "systemd-zfs-generator" that would run early in boot, or a direct modification of /etc/fstab. There are pros and cons to each of them. The systemd-zfs-generator only really seemed to me to have one advantage:

1. Doesn't clutter your /etc/fstab with a bunch of generated lines

But putting all this junk in /etc/fstab can get out of sync with the options already stored in "the right place" in the filesystem itself, you say! Certainly that is a disadvantage! From man systemd.generator

Generators are small executables that live in /lib/systemd/system-generators/ and other directories listed above. systemd(1) will execute those binaries very early at bootup and at configuration reload time -- before unit files are loaded.

Emphasis added. We cannot hope to have access to the zpool (i.e., cannot run zfs list) when any systemd generators are going to be run.

So, we need the dependency information, which is properly encoded in the file system hierarchy, at early boot time to generate the ideal boot ordering. Where should we store that?

POSIX specifies that place: /etc/fstab.

As an aside: if you have multiple pools, you would also like the ordering information to reflect the multiple pool imports, which can take quite a while. That information must also be necessarily stored outside the pool.

[codecov]

Codecov Report

Merging #6974 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6974      +/-   ##
==========================================
+ Coverage   75.55%   75.58%   +0.02%     
==========================================
  Files         296      296              
  Lines       95483    95454      -29     
==========================================
  Hits        72145    72145              
+ Misses      23338    23309      -29

Flag	Coverage Δ
#kernel	74.93% <ø> (-0.09%)	⬇️
#user	68.03% <ø> (+0.05%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 390d679...1077db2. Read the comment docs.

[aerusso]

I'll rework this idea and open another PR when it's ready.