-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Systemd: Replace zfs-mount.service with systemd.generator(7) #4898
Comments
This is an important thing to address. I have service units which feature RequiresMountsFor= flags specifying ZFS mounts, which are completely ignored as systemd isn't aware of those mounts (or the subsequent ZFS service dependencies). |
I don't think this is a good idea. We should just put zfs mount point in fstab let systemd-fstab-generator do the work. What we need is a mechanism to select pools to import according to fstab and import them in local-fs-pre.target. |
Using fstab to enumerate zfs pools and filesystems seems counter to the way zfs is meant to be managed (that is, wholly through the zfs/zpool interfaces). Effort spent in creating zfs filesystems would need to be duplicated to fstab. It seems to be that fstab is becoming a legacy file, with the trend nowadays towards filesystems being exposed to system when scanned via udev/systemd. |
As a data point, it is important that users do not create their own mount points for zfs. I just diagnosed my own problem with this error , and had forgotten that I created /zfsmount (say) then /zfsmount/stuff . zfs mount -a kept complaining cannot mount '/zfsmount': directory is not empty, which now I understand is correct. if you do "mount |grep zfs" and see /zfsmount/stuff without /zfsmount on its own, you will get this error. zfs creates its own mount points and there should be nothing in fstab to contradict that, until zfs is up and running. |
just a kind reminder that this issue has no milestone no label, pinging @behlendorf |
There has been some progress on this front and a proposed prototype for comment, review and testing in #4943. We'd love to get some feedback on it. |
This was resolved by PR #7329, right? |
After debugging a new installation with /var in a separate dataset for a day, I'm now under the impression that the current way of mounting zfs datasets on boot is completely broken. Several bug reports in this tracker confirm this (#3768, #4784, #4474, etc...).
It seems to me that zfs should follow the normal way of mounting filesystems on systemd (using mount-units that are auto-generated by systemd-fstab-generator). Benefits would be that systemd will ensure that all mounts are done in the correct order (even if zfs- and fstab-mounts are interleaved) and that nothing will write into the empty directories right before mounting.
To achive this, one would have to write a systemd.generator(7) that outputs one mount-unit for each dataset that would be mounted by
zfs mount -a
. This generator is run when systemd starts up, so that might be difficult for some reason (I never wrote software for early boot).Am I missing something or could that actually work?
The text was updated successfully, but these errors were encountered: