Date: Thu, 19 Mar 2026 21:56:50 -0700 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@freebsd.org> Cc: Martin Matuska <mm@freebsd.org>, h v <henry.vogt@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: zfs module not loaded anymore on e.g MINIMAL Message-ID: <CANCZdfpF7GYLRPWvRSX1uKqKLZGPZB5Bg-Sd8t3xabVSHoCeOg@mail.gmail.com> In-Reply-To: <86wlz73g23.fsf@ltc.des.dev> References: <5913b3ac-2ed7-42ab-9c26-0d204c38c578@gmail.com> <CANCZdfq8gxi2ywvfvCdC%2Bsoqu_9-XPFrvqNNeGqjsJbUfkLoXg@mail.gmail.com> <fdb20aa1-46e6-41ff-83a4-8549ed56c316@gmail.com> <CANCZdfpQnALFj%2B5Hd0xC-5yO3wzjOmZG9TYQL6tWbHr_%2By%2BRFQ@mail.gmail.com> <299d29ce-98b9-4daf-aed7-a8cc9cd3a45f@FreeBSD.org> <86a4w3517o.fsf@ltc.des.dev> <CANCZdfpB7HoeQe9_rxHRQocYGM8DcZn9un-9YdmjBS8tzr6vsQ@mail.gmail.com> <861phf4uu3.fsf@ltc.des.dev> <86wlz73g23.fsf@ltc.des.dev>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Thu, Mar 19, 2026 at 10:05 AM Dag-Erling Smørgrav <des@freebsd.org> wrote: > Dag-Erling Smørgrav <des@FreeBSD.org> writes: > > Warner Losh <imp@bsdimp.com> writes: > > > Any reason zstd can't be a module? > > I had the same thought but it's going to take a bit of work. We'll have > > to split up sys/kern/subr_compress.c into separate files for each > > backend (currently gzio and zstdio), add module Makefiles, and figure > > out how to make dumps dynamically use whatever compression is available. > > Actually I think this last bit is already in place. We just need to > have each compression method register with subr_compress on load (and > unregister on unload, which I don't think subr_compress currently > supports). We also need to keep a running count of compression / > decompression contexts to prevent unloading a method while it's in use. > So I guess go ahead with the kernel config changes (though I don't like having to do that, there's no easy alternative). I wonder what the best way to document this so that it doesn't get list in the future... Warner [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2026 at 10:05 AM Dag-Erling Smørgrav <<a href="mailto:des@freebsd.org">des@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dag-Erling Smørgrav <des@FreeBSD.org> writes:<br> > Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank">imp@bsdimp.com</a>> writes:<br> > > Any reason zstd can't be a module?<br> > I had the same thought but it's going to take a bit of work. We'll have<br> > to split up sys/kern/subr_compress.c into separate files for each<br> > backend (currently gzio and zstdio), add module Makefiles, and figure<br> > out how to make dumps dynamically use whatever compression is available.<br> <br> Actually I think this last bit is already in place. We just need to<br> have each compression method register with subr_compress on load (and<br> unregister on unload, which I don't think subr_compress currently<br> supports). We also need to keep a running count of compression /<br> decompression contexts to prevent unloading a method while it's in use.<br></blockquote><div><br></div><div>So I guess go ahead with the kernel config changes (though I don't like having to</div><div>do that, there's no easy alternative). I wonder what the best way to document this so</div><div>that it doesn't get list in the future...</div><div><br></div><div>Warner </div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpF7GYLRPWvRSX1uKqKLZGPZB5Bg-Sd8t3xabVSHoCeOg>