ZFS committed to the FreeBSD base.

[Kostik Belousov]

On Wed, May 02, 2007 at 05:28:04PM -0400, Rick Macklem wrote:
> 
> 
> On Wed, 2 May 2007, Robert Watson wrote:
> [stuff snipped] 
> >
> >Historically, such panics have been a result of one of two things:
> >
> >(1) An immediate resource leak in UMA(9) or malloc(9) allocated memory.
> >
> >(2) Mis-tuning of a resource limit, perhaps due to sizing the limit based 
> >on
> >   solely physical memory size, not taking available kernel address space
> >   into account.
> >
> >mti_stats reports only on malloc(9), you need to also look at uma(9), 
> >since many frequently allocated types are allocated directly with the slab 
> >allocator, and not from kernel malloc.  Take a look at the output of "show 
> >uma" or "show malloc" in DDB, or respectively "vmstat -z" and "vmstat -m" 
> >on a core or on a live system.  malloc(9) is actually implemented using 
> >two different back-ends: UMA-managed fixed size memory buckets for small 
> >allocations, and direct page allocation for large allocations.
> 
> Ok, it does appear I'm leaking NAMEIs. "vmstat -z", which I didn't know
> about, was the trick. Handling lookup name buffers is also port specific,
> so it wouldn't have shown up in the other ports.
> 
> So, forget what I said w.r.t. a MALLOC bug and thanks for the help. I
> should be able to locate the leak pretty easily with "vmstat -z".
I fixed two NAMI zone leaks in the last 2-3 month. One was in the nfs
server (shall be present in 6.2-RELEASE, AFAIR), second was in UFS
snapshotting code, and is MFCed several days ago.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070503/c291d2f1/attachment.pgp