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

CONFIG_ZFS_FS rule for Linux #637

Closed
bademux opened this issue Apr 4, 2012 · 10 comments
Closed

CONFIG_ZFS_FS rule for Linux #637

bademux opened this issue Apr 4, 2012 · 10 comments
Labels
Type: Building Indicates an issue related to building binaries
Milestone

Comments

@bademux
Copy link

bademux commented Apr 4, 2012

Support linux kernel build infrastructure.

@ryao
Copy link
Contributor

ryao commented Apr 4, 2012

Would you elaborate on how you envision this being done?

@behlendorf
Copy link
Contributor

Please do, since we already rely heavily on the kernel build infrastructure. What do you mean?

@bademux
Copy link
Author

bademux commented Apr 4, 2012

Sorry for the late response.
it would be nice to add the ability of the configuration zfs module from kernel's global configuration (and may be with visual tools like menuconfig).
btw, thank you for the great peace of software.

@ryao
Copy link
Contributor

ryao commented Apr 5, 2012

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.

@bademux
Copy link
Author

bademux commented Apr 7, 2012

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

@behlendorf
Copy link
Contributor

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.

@ryao
Copy link
Contributor

ryao commented Apr 10, 2012

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.

@behlendorf
Copy link
Contributor

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.

openzfs/spl@7440380
4ab8a72

For those interested in this change, please give it a try.

@bademux
Copy link
Author

bademux commented Jul 31, 2012

thanks

@ryao
Copy link
Contributor

ryao commented Jul 31, 2012

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.

behlendorf pushed a commit to behlendorf/zfs that referenced this issue May 21, 2018
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
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Building Indicates an issue related to building binaries
Projects
None yet
Development

No branches or pull requests

3 participants