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