When will ZFS become stable?
rwatson at FreeBSD.org
Tue Jan 8 11:22:37 PST 2008
On Wed, 9 Jan 2008, Vadim Goncharov wrote:
>>> Yes, I've known it, but didn't known what column names exactly mean.
>>> Requests/Failures, I guess, is a pure statistics, Size is one element
>>> size, but why USED + FREE != LIMIT (on whose where limit is non-zero) ?
>> Possibly we should rename the "FREE" column to "CACHE" -- the free count is
>> the number of items in the UMA cache. These may be hung in buckets off the
>> per-CPU cache, or be spare buckets in the zone. Either way, the memory has
>> to be reclaimed before it can be used for other purposes, and generally for
>> complex objects, it can be allocated much more quickly than going back to
>> VM for more memory. LIMIT is an administrative limit that may be
>> configured on the zone, and is configured for some but not all zones.
> And every unlimited zone after growing on demand can cause
> kmem_map/kmem_size panics, or some will low-memeory panics with message
> about another map?
Well, there are also limits not imposed using the UMA limit mechanism, so just
because it appears unbounded in vmstat -z doesn't mean there's no limit.
There's no UMA zone limit on processes, but there's a separately imposed
maxproc limit--and as a result, filedesc, which is typically one per process,
is also bounded to approximately maxproc. Likewise, many other data
structures effectively scale with the number of processes, the size of
physical memory, the size of the address space, maxusers, etc.
There are relatively few things that actually have no limit associated with
them one way or another, precisely because if there's no limit it can lead the
kernel to become starved of resources. Where there isn't a limit, ideally
privilege is required to allocate (i.e., malloc-backed swap requires root
privilege to configure). Sometimes the limits are much more complex than a
single global limit, such as resources controlled using resource limits, which
can be per-process, per-uid, etc.
Robert N M Watson
University of Cambridge
More information about the freebsd-current