Open aamkye opened 1 year ago
This "tutorial" is based on my PoC and HomeLab installation via Ansible tested on ubuntu server 22.10.
Will need to update docs according to #396
Why don't we just add part about services (and other small nits) into Building ZFS.rst as additional section? Looks like a duplicate otherwise, we already have 2 instructions about building from source.
So maybe we should merge them into one covering all details?
@gmelikov I'll prepare something (merged doc) according to the docs and my knowledge.
@aamkye yes, I've meant that we may just add needed things to existing page.
Side note - while it may be handy, I don't think it would be great to add parts about ansible. We may describe ansible somewhere else and add a link to it (maybe whole playbook example as yaml file? But we'll need to maintain it).
Valid point Sir! So let's stick to bash commands and bash commands only in this repo :)
Just to be on the same page, we already have:
I think the best place is https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html , because the point is to get working custom packages, not just build modules.
@gmelikov I've also found that besides missing services there are also a missing cron jobs: scrub
and trim
and scripts:
/usr/lib/zfs-linux/trim
/usr/lib/zfs-linux/scrub
I think it also should be part of the documentation, shouldn't it?
@aamkye in fact, there are 2 types of packages in any project:
So, we may describe explicitly about such difference, and that our documentation speaks about first type. That mean is that (for example in Debian) if you want to get 100% identical package to original distro's one - you need to rebuild from distro's source package, not project's one.
If project's package misses something - we may discuss to add missing parts in our packages.
So, any of additions in docs may describe just notes about which functionality may be added, but we should now describe them as "must haves" (because in this case we should add them into packages, not into documentation).
You may be interested to read this thread with Debian's package maintainer https://github.com/openzfs/zfs/pull/13451
@gmelikov, I was investigating the deb package from ubuntu (apt download zfsutils-linux
+ dpkg-deb -R zfsutils-linux_2.1.5-1ubuntu6_amd64.deb
) against what we have in openzfs/zfs/etc/systemd/system, and it differs, What is more, services and crons are handled a bit different. In our package we are not using crontab
but we use systemd timers:
user@server:~$ systemctl cat zfs [tab]
zfs-import-cache.service zfs-load-key.service zfs-scrub-weekly@.timer zfs-volume-wait.service
zfs-import-scan.service zfs-mount.service zfs-share.service zfs-zed.service
zfs-import.service zfs-scrub-monthly@.timer zfs.target
zfs-import.target zfs-scrub@.service zfs-volumes.target
And if fact those services and timers are present in the system. Going further, on the ./autogen.sh
and ./configure
scripts there is a dependency to the 50-zfs.preset which theoretically should enable those services by default but apparently they are not.
Right now I'm trying to determine a common sense, but any clarification would be helpful in favor of future documentation.
Another issue is the fact that native-deb
is not working on master, but I assume it will be on ZFS 2.2 release.
Yep, that's exactly what I'm talking about - every Linux distribution may have it's own package with differences and patches. We even can't describe uniform deb info because Ubuntu, Debian and Proxmox all have their own packages.
So maybe as a ZFS community, we could gather people from different distros and prepare a repository to prepare such packaging for each distribution containing guidelines, tutorials, and scripts to do so not only for the ZFS project but for more. Because it seems I've entered a rabbit hole and it goes waaaaay deeper than I thought.
It's true that we may gather good and universal parts together in our original packages, but it's normal for major distribution to have alterations in packages.
I can add even more - Debian maintainers want to use their own packages even after native debs were pulled into our master (it's ok to track package build parts separately from upstream project).
So, we can highlight these things in documentation:
I was missing this info, so I'm glad to provide them :) Please let me know if certain information is missing.