-
Notifications
You must be signed in to change notification settings - Fork 28
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
New Package Request: sys-fs/zfs #1110
Comments
Hi, this module and the ZFS tools are essential in a Kubernetes environment to manage persistent storage. For now, we've forked the repo systext-bakery and built the ZFS module for our use. It's currently a proof of concept, but we'll use it in our production environment soon. This might help the integration of the ZFS module in Flatcar. |
Interesting, since the image is pretty much linked to the base OS version I think you should use |
Very nice. |
@pothos , in fact we re-use this work : https://github.com/jepio/flatcar-zfs-overlay/blob/main/Dockerfile to build the extension. But you are right, the extension is linked to a specific Flatcar version (since we build the modules with a specific kernel version). Also, as we build the module ourselves, it's not signed with the key used to build the kernel, so the kernel is taint, but i'm not sure it's a issue. @jhaprins , you can clone the repo and modify somes files to build the right module version. |
@donch have you worked out the secret sauce for systemd to load the zfs module and import your pool before docker starts? That's where I'm stuck. My home fileserver was happily running zfs using torcx, but trying to migrate to flatcar has been painful. Doubly so as I don't have much time to poke at it unfortunately. I forked jepio's repo too, but added github workflows that build and publish both a docker image and squashfs raw file. It also includes the
(I have a script that subs in the version ahead of transpiling to ignition.) So I successfully have the overlay fully loaded, but it isn't automatically loading the kernel module. I can manually |
You'll have to make systemd-modules-load.service run after the sysext service (via dropins), and enable all the zfs services/targets manually. And then you'll probably also need to add a dependency between containerd (or docker) and zfs.target (I think). I wrote about this problem here: https://groups.google.com/g/flatcar-linux-user/c/RX9ZO_hX1JA/m/OLgMYoTHAgAJ. |
Exact.
|
|
I was able to build your overlay module for version 3689 with ZFS 2.1.11. Now lets see if it loads. |
@jhaprins Could you please provide an update on this ticket? Thank you |
The module loads and I can see the kernel modules loaded and everything, so that looks all fine. Have not yet tested creating filesystems etc, because the test system I'm currently using it on does not have extra disks installed. Will try to get this done somewhere later this week, can't promise at the moment though. |
@donch do you have an explanation why a test pool I created won't import on boot? |
Hi @jhaprins , i had this error when i upgraded Flatcar and ZFS version. The pool scanning wasn't ran because of systemd condition. In my case i had to remove the file /etc/zfs/zpool.cache after the upgrade, then the pool is correctly discover at the next boot. |
@donch Could you contact me regarding your sysext-bakery repository? I'm running into some issues when I try to use your repo so I can build against the latest beta of Flatcar. I would be happy to do this outside of this ticket. You can mail me at jhp at jhprins dot org |
@donch I'm currently working on building the sysext module in the SDK environment instead of the sysext-bakery, that way it will be easier to integrate it later into the central build repository of Flatcar itself. In your sysext-bakery repo you build everything and in the image the files belonging in /etc are located in /usr/etc. Where in the whole load process do you put them into /etc? I can't seem to find this. |
A Flatcar ZFS extension is released as part of the latest Alpha (flatcar/scripts#1742) |
Package name and purpose
A filesystem perfectly suited for hosting the storage in a Kubernetes environment.
Impact of adding this package to the Flatcar OS image
The package improves on the following core values:
The package will increase the image size by: Unknown MBytes.
How might this package increase the attack surface:
Benefits of adding this package
This filesystem is promoted to be the best for storage in a K8S environment. I think I also saw talks and documentation from the Flatcar community that said this filesystem should be used when available. This was the reason for us when we did the initial selection to mark that this was in this OS. Finding this is not the case, surprised us a little, and now I'm investigating what needs to be done to get it in the OS.
I don't know if adding this package is the only thing needed to get this working, I can imagine that some kernel modules are also needed to get all ZFS functionality.
A side note, I don't need to be able to boot from a ZFS filesystem or anything like that. I just need to be able to create ZFS storage for the K8S cluster that is hosted on the Flatcar systems.
Additional information
[ Please add any information that does not fit into any of the above sections here ]
The text was updated successfully, but these errors were encountered: