Skip to content
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

Closed
pyropeter opened this issue Jul 28, 2016 · 7 comments
Closed

Systemd: Replace zfs-mount.service with systemd.generator(7) #4898

pyropeter opened this issue Jul 28, 2016 · 7 comments
Labels
Type: Feature Feature request or new feature

Comments

@pyropeter
Copy link

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?

@smopucilowski
Copy link

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).

@tuxoko
Copy link
Contributor

tuxoko commented Jul 29, 2016

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.

@smopucilowski
Copy link

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.

@neurotensin
Copy link

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.

@mailinglists35
Copy link

just a kind reminder that this issue has no milestone no label, pinging @behlendorf

@behlendorf
Copy link
Contributor

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.

@rlaager
Copy link
Member

rlaager commented Jul 19, 2018

This was resolved by PR #7329, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

7 participants