lkml.org 
[lkml]   [1999]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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--
\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.034 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site