Messages in this thread | | | Date | Tue, 16 Mar 1999 14:15:23 -0000 (GMT) | From | Martin Poole <> | Subject | Re: SAR for Linux? |
| |
On 15-Mar-99 Greg Franks wrote: > > Alas, there is insufficient accounting of disk information along the > lines of Sun's iostat. > > I am presently planning on bashing the kernel to add this information. > ..greg >
Work's already been done by Stephen Tweedie (see enclosed message) Newer version is available in the same directory
ftp://ftp.uk.linux.org:/pub/linux/sct/fs/
-- Martin Poole, Perot Systems Europe mpoole@quatermass.hea.ps.net Content-Length: 1657 Return-Path: <owner-linux-kernel-outgoing@vger.rutgers.edu> Received: by vger.rutgers.edu id <156680-17165>; Fri, 4 Dec 1998 12:16:20 -0500 Received: from dax.scot.redhat.com ([195.89.149.242]:1930 "EHLO dax.scot.redhat.com" ident: "sct") by vger.rutgers.edu with ESMTP id <157636-17165>; Fri, 4 Dec 1998 07:46:37 -0500 Received: (from sct@localhost) by dax.scot.redhat.com (8.8.7/8.8.7) id PAA04690; Fri, 4 Dec 1998 15:07:07 GMT Date: Fri, 4 Dec 1998 15:07:07 GMT Message-Id: <199812041507.PAA04690@dax.scot.redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" In-Reply-To: <Pine.LNX.4.02.9812031333410.929-100000@einstein.london.sco.com> References: <3663B634.F5F964E7@dial.oleane.com> <Pine.LNX.4.02.9812031333410.929-100000@einstein.london.sco.com> X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO XFMstatus: 0000 Sender: owner-linux-kernel@vger.rutgers.edu From: "Stephen C. Tweedie" <sct@redhat.com> To: Tigran Aivazian <tigran@aivazian.demon.co.uk> Subject: SAR (was Re: disks stats through /proc) Cc: jfontain@multimania.com, linux-kernel@vger.rutgers.edu, Stephen Tweedie <sct@redhat.com>
--MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,
On Thu, 3 Dec 1998 13:39:42 +0000 (GMT), Tigran Aivazian <tigran@aivazian.demon.co.uk> said:
> IMHO, this should be done on a fine-grained (partition level) rather than > coarse (drive) level. There is enough information in > ll_rw_blk.c/add_request() to do it now but, of course, kernel_stat > structure will have to be seriously modified.
> There is something frustrating about the quality and speed of Linux > development. I.e. the quality is too high and the speed is too high, > in other words, I can implement this disk stat feature, but I bet > someone else has already done it and is just about to release his > patch to Linus soon...
Yep, done that. :)
I have patches for 2.0.34/35 and 2.1.125 already working, outputing both per-partition and per-spindle access stats via /proc/partitions. A "sard" front-end gives human-readable output. (It is modeled on the output of the SVR4 "sar -d" output.)
Currently you get average %utilisation; average request queue length; number of K transfered plus number of distinct IOs for reads, writes and combined; and average request service time for each disk and each partition.
Look for
ftp://ftp.uk.linux.org:/pub/linux/sct/fs/sard-0.2.tar.gz
for the patches and sard source code. The plan is to integrate this into 2.3 once we have got a more sensible kdev_t in the kernel.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ --MimeMultipartBoundary--
| |