Date: Tue, 7 Jan 2003 15:15:52 +0100 From: "Willem Jan Withagen" <wjw@withagen.nl> To: "Bruce Evans" <bde@zeta.org.au>, <phk@FreeBSD.ORG> Cc: <current@FreeBSD.ORG> Subject: Re: panic with panic: kmem_malloc(4096): kmem_map too small... Message-ID: <02cb01c2b657$4e483440$471b3dd4@dual> References: <20030107215110.Y7843-100000@gamplex.bde.org>
index | next in thread | previous in thread | raw e-mail
> 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).
I'd be interested in that block number printing program too....
After some discussion offline with Poul-Henning that was exactly what is one of the basic needs to do any analysis in this area:
A way to determing a fragmentation degree/index.
Poul suggested then bean-counting in fsck, so I started looking there. But the 'block number printing' would generate even better data.
I'm building a system just for running some of these test on it.
Feel free to suggest or discuss the approach.
--WjW
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02cb01c2b657$4e483440$471b3dd4>