From owner-freebsd-current Tue Jan 7 4: 6:41 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 837FB37B401; Tue, 7 Jan 2003 04:06:40 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3234D43ED1; Tue, 7 Jan 2003 04:06:39 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA29804; Tue, 7 Jan 2003 23:06:30 +1100 Date: Tue, 7 Jan 2003 23:07:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: phk@FreeBSD.ORG Cc: Willem Jan Withagen , Subject: Re: panic with panic: kmem_malloc(4096): kmem_map too small... In-Reply-To: <31595.1041930665@critter.freebsd.dk> Message-ID: <20030107215110.Y7843-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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