Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Sep 2002 19:07:17 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Greg 'groggy' Lehey <grog@FreeBSD.org>, Jeff Roberson <jeff@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_alq.c src/sys/sys alq.h
Message-ID:  <20020923020717.GC6262@elvis.mu.org>
In-Reply-To: <20020922211607.E43954-100000@mail.chesapeake.net>
References:  <20020923003727.GM21093@wantadilla.lemis.com> <20020922211607.E43954-100000@mail.chesapeake.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [020922 18:28] wrote:
> On Mon, 23 Sep 2002, Greg 'groggy' Lehey wrote:
> 
> > On Sunday, 22 September 2002 at  0:11:14 -0700, Jeff Roberson wrote:
> > > jeff        2002/09/22 00:11:14 PDT
> > >
> > >   Added files:
> > >     sys/kern             kern_alq.c
> > >     sys/sys              alq.h
> > >   Log:
> > >    - Add an asynchronous fixed length record logging mechanism called
> > >      ALQ (Asynch. Logging Queues).  ALQ supports many seperate queues with
> > >      different record and buffer sizes.  It opens and logs to any vnode so
> > >      it can be used with character devices as well as regular files.
> >
> > What's the purpose of this functionality?
> >
> > Greg
> > --
> > See complete headers for address and phone numbers
> >
> 
> Well, for now it's only used by ktr.  I believe that it could be applied
> to other areas as well.  In general I need it for recording long term
> events such as disk or network activity for post analysis.  It could also
> be useful for diagnosing problems with VFS by logging all VOPs via ktr.
> 
> It could also be used for logging binary kernel data w/o going through
> ktr.  Any subsystem could create a queue and record it's actions over a
> long period.  ktrace could be implemented on top of an ALQ, although this
> would be slightly more difficult since it does not use fixed length
> records.

Have you thought of running it into a fifo with gzip waiting on the
other side?  I guess that could sort of cause an infinite loop if
you were recording certain process/vnode interaction unless it was
batched up somehow.

-Alfred

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020923020717.GC6262>