When you start hooking up 100's of 'physical volumes' (be it real disks or
raided logical drives)
this data helps you pin-point problems. I think the idea of having the
ability to turn such accounting
on/off via /proc entry a very nice method of doing things.
That way you can leave it off for normal run-time but when users complain or
DBA's et al
you can turn it on get some stats for a couple hours/days whatever, then
turn it back off and
plan an upgrade or re-create a logical volume or stripping set.
Steve
----- Original Message -----
From: "Chris Evans" <chris@scary.beasts.org>
To: <Tony.Young@ir.com>
Cc: <chris@scary.beasts.org>; <slug@slug.org.au>; <csa@oss.sgi.com>;
<linux-kernel@vger.kernel.org>
Sent: Monday, January 29, 2001 07:26
Subject: RE: Linux Disk Performance/File IO per process
>
> On Mon, 29 Jan 2001 Tony.Young@ir.com wrote:
>
> > Thanks to both Jens and Chris - this provides the information I need to
> > obtain our busy rate
> > It's unfortunate that the kernel needs to be patched to provide this
> > information - hopefully it will become part of the kernel soon.
> >
> > I had a response saying that this shouldn't become part of the kernel
due to
> > the performance cost that obtaining such data will involve. I agree that
a
> > cost is involved here, however I think it's up to the user to decide
which
> > cost is more expensive to them - getting the data, or not being able to
see
> > how busy their disks are. My feeling here is that this support could be
user
> > configurable at run time - eg 'cat 1 > /proc/getdiskperf'.
>
> Hi,
>
> I disagree with this runtime variable. It is unnecessary complexity.
> Maintaining a few counts is total noise compared with the time I/O takes.
>
> Cheers
> Chris
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/