Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Jan 2003 23:07:00 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        phk@FreeBSD.ORG
Cc:        Willem Jan Withagen <wjw@withagen.nl>, <current@FreeBSD.ORG>
Subject:   Re: panic with panic: kmem_malloc(4096): kmem_map too small... 
Message-ID:  <20030107215110.Y7843-100000@gamplex.bde.org>
In-Reply-To: <31595.1041930665@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Jan 2003 phk@FreeBSD.ORG wrote:

> In message <01e701c2b62b$db07ddd0$471b3dd4@dual>, "Willem Jan Withagen" writes:
> >I was able to copy the full 100+Gb.
> >Next I'm going to try and fill the disk to the max as user, but i guess it'll not trigger this bug.
> >
> >And to that fact I have a question:
> >    At the moment 8% of the disk is reserved.
> >    It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot.
> >    tunefs lets me bring that down to 5% = 8,5Gb without speed penalty.
> >    But is for this size of spare space such a large threshold really required??
> >    And IF i would like to experiment, where do I look for the knop to turn??
>
> Basically you don't need to reserve anything, but as you get closer to
> filling the disk the time to find a free space increases rapidly and
> your files get very fragmented.  Trouble is: they never get defragmented
> unless you copy them (or do a full dump/restore).

File get quite fragmented (enough to lose a factor of 2 or so of the
disk's bandwidth) even when the disk is almost empty.  Then they don't
get defragmented unless you copy them, etc.  The Real Fragmentation
that occurs when a disk is nearly full loses a much larger factor of
the disk's bandwidth.

> I'm not sure how to nail the "right" number of % down, and I'm sure
> that both Kirk and I would like to hear your numbers :-)

I postprocess output from Kirk's block number printing program to
produce fragmentation estimates.  All (non-null) seeks are considered
to be fragmentation.  A (logical) non-null seek seems to be normal for
about 10% of (logical) i/o's even in the favourable case of files
created by copying to an initially empty filesystem (this is for
small files like the ones in FreeBSD's src tree).

Bruce


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




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