-
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
CONFIG_ZFS_FS rule for Linux #637
Comments
Would you elaborate on how you envision this being done? |
Please do, since we already rely heavily on the kernel build infrastructure. What do you mean? |
Sorry for the late response. |
Exactly how do you envision us doing this? Are you asking for a patch set for the Linux kernel sources or are you asking us to provide our own patched tarball? So far, this sounds like something more appropriate to request downstream, although I would expect the downtream maintainer(s) to suggest using an initramfs generator like genkernel to attain similar results. |
I think that an archive of a particular version of the kernel is the best solution, because there are many questions which kernel version is the most zfs-stable |
I'd prefer to avoid creating patched kernel archives, it would become too much of a maintenance burden. If your just looking for the most stable version of ZFS for a production environment I would suggest using one of the Enterprise Linux Distributions, RHEL or SLES. These experience the least change on the kernel side while still getting critical security updates. At LLNL we target RHEL so that certainly gets a lot of testing and abuse. If you need/want to run something more current then I'd stick with one of the downstream distro versions. They will be the best integrated with your distro and receive considerable testing. Currently, Gentoo and Ubuntu are the distributions I'd recommend if your not going to use an Enterprise distro. |
For what it is worth, Gentoo is capable of booting with RHEL's kernel, although you would need to import one of the Funtoo packages if you want the package manager to install RHEL's kernel for you. http://www.funtoo.org/wiki/Funtoo_Linux_Kernels Gentoo maintains multiple packages for different kernel patch sets, such as sys-kernel/hardened-sources and sys-kernel/zen-sources. In the context of this, I can imagine Gentoo having sys-kernel/zfs-sources, which would provide what @bademux wants. With that said, I cannot imagine anyone volunteering to maintain this. It is a big commitment, my hands are already full with sys-fs/zfs and Gentoo's developer resources are already stretched thin. |
A bit to my surprise this actually got done as issue #851. Etienne Dechamps did the heavy lifting and extended the build infrastructure so it can be easily used to patch zfs in to a kernel source tree. The changes has been merged in to master, see the following commits for details. For those interested in this change, please give it a try. |
thanks |
Here is a patch that you can apply to your kernel sources to add ZFS support: http://dev.gentoo.org/~ryao/dist/linux-3.5.0-zfs.patch If you want to build it into the kernel binary, you should also apply this patch: http://dev.gentoo.org/~prometheanfire/dist/kernel-patches/linux-3.5.0-zfs-builtin.patch Lastly, I recommend applying this patch regardless of whether ZFS is built into the kernel or not: http://dev.gentoo.org/~prometheanfire/dist/kernel-patches/linux-3.5.0-gfp-vmalloc.patch It will prevent deadlocks. |
Prevent race on accessing kmutex_t when the mutex is embedded in a ref counted structure. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Chunwei Chen <david.chen@osnexus.com> Signed-off-by: Gvozden Neskovic <neskovic@gmail.com> Closes openzfs#6401 Closes openzfs#637
We sometimes see memory usage of the agent process grow very large over time, with the vast majority of it unaccounted for by our allocation tracking. Investigation revealed that most of the memory usage was unallocated parts of the heap, which were likely stranded due to memory fragmentation, exacerbated by periodic floods of large allocations (and then frees a few seconds later) due to zettacache index merging. This commit switches the agent to use jemalloc, which is less subject to memory fragmentation. The process's memory usage (RSS) now more closely tracks the amount of currently-malloc'd memory. Additionally, jemalloc uses less CPU time, and overall performance of zettacache ingestion improved by up to 25%. This commit also implements the alloc_zeroed() and realloc() methods of the GlobalAlloc trait, enabling use of the underlying optimized versions in jemalloc, which contributes to the above mentioned overall performance improvement.
Support linux kernel build infrastructure.
The text was updated successfully, but these errors were encountered: