ZFS_DEBUG + enable ZFS ASSERTS with INVARIANTS any objections?

Matthew Ahrens mahrens at delphix.com
Tue Jul 2 17:30:04 UTC 2013


On Tue, Jul 2, 2013 at 12:08 AM, Andriy Gapon <avg at freebsd.org> wrote:

> on 02/07/2013 09:51 Matthew Ahrens said the following:
> > If I understand correctly, INVARIANTS is a mechanism that enables
> > additional runtime checks in the kernel, analogous to DEBUG enabling
> > ASSERTions in Solaris-derived code.
>
> Yes.
>
> > You want to turn on ZFS_DEBUG and
> > assertions within ZFS without setting DEBUG in general.
> >
> > Why do you want to do this?
>
> Because in larger FreeBSD kernel DEBUG has already been used for other
> purposes.
>  In some place it enables lots of printfs that typically are of no
> interest but
> can easily spam logs / message buffer.
>

Ah, so you'd be happy if Solaris had called it SOLARIS_DEBUG instead of
simply DEBUG.  You were just "lucky" that ZFS already renamed it to
ZFS_DEBUG (but this is only used in a few cases).

Seems like the possible solutions are:

 - change DEBUG in all your solaris-derived code to INVARIANTS (or
something other than DEBUG)
this introduces maintenance burden when merging with upstream

 - change your build process to use -DDEBUG on solaris-derived code when
INVARIANTS is set
I believe this is what Justin proposed in the first response in this thread.

--matt


>
> > Why not set DEBUG and turn on all assertions
> > in Solaris-derived code?  If it is performance, how much slow down do
> > non-ZFS assertions cause?  If it's too much, can we fix that?
> >
> > I'm not sure why ZFS_DEBUG exists, rather than just using DEBUG.  It may
> be
> > historical; now it seems that ZFS_DEBUG and DEBUG are always set together
> > (including in libzpool).  Unless there's a good reason for them to be
> > separate, I'd rather see ZFS_DEBUG removed, and use DEBUG instead.
>
>
>
> --
> Andriy Gapon
>


More information about the zfs-devel mailing list