ZFS committed to the FreeBSD base.
ticso at cicely12.cicely.de
Sat Apr 7 18:03:31 UTC 2007
On Sat, Apr 07, 2007 at 06:58:00PM +0200, Bernd Walter wrote:
> On Sat, Apr 07, 2007 at 03:59:02PM +0200, Florian C. Smeets wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Pawel Jakub Dawidek wrote:
> > > On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote:
> > >> My sandbox just has 128MB RAM so kmem was set to ~40M.
> > >> After raising kmem to 80M it survived copying the file, but paniced
> > >> again while tar -xvzf the file into the same pool.
> > >> vfs.zfs.vdev.cache.size is unchanged at 10M.
> > >
> > > 128MB RAM of suggested minimum in ZFS requirements, but it may be not
> > > enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever
> > > is more). Could you locate these lines in
> > > sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file:
> > >
> > > /* set min cache to 1/32 of all memory, or 64MB, whichever is more */
> > > arc_c_min = MAX(arc_c / 4, 64<<20);
> > >
> > > Change 64 to eg. 32, recompile and retest?
> > >
> > Hi Pawel,
> > i had the same problems like Bernd while trying to copy the src tree to
> > a ZFS volume. I have 384MB RAM but i got the same "kmem_map: too small"
> > panic. I compiled my kernel like you proposed and now i am able to copy
> > anything to the volume without panic :-)
> I had increased RAM to 384 and still had a panic with default kmem
> (IIRC around 100M) and even increasing kmem to 160M did help a long
> time, but still produced the panic after a while.
> I don't think 64M applies here as the real limit.
Now with 240M kmem it looks good, but I'm still unshure:
c_max seemed to be increasing with kmem, but I did compare it with a
Should be good with:
But top shows wired memory which is roughly twice the size of
arcstats.size, so I'm still worried about kmem exhaustion if ARC runs
up to c_max.
Since the c_min/c_max values also influence the available RAM for other
purposes as well, can we have it at least a loader.conf tuneable?
Otherwise - the reboot after the panics where impressive.
No long fsck times or noticed data corruption - even with NFS clients.
All in all it is a great job.
B.Walter http://www.bwct.de http://www.fizon.de
bernd at bwct.de info at bwct.de support at fizon.de
More information about the freebsd-current