Re: IO stats in /proc/partitions

Re: IO stats in /proc/partitions

[Andries.Brouwer]

Earlier I noticed that RedHat did put some statistics in
/proc/partitions. That was bad, but I assumed that it was
their laziness, being too busy to do a proper job.

However, I see that these days the pollution of /proc/partitions
is becoming official - it is part of patch-2.4.19-pre7.
I strongly object, and hope it is not too late to revert this.

Things must do one thing, and one thing well.
The task of /proc/partitions is to list which partitions the
kernel knows about. When I implemented it I thought that adding
the starting offset would be superfluous, but in fact I now realize
that that is required for several applications.
So, /proc/partitions must be updated sooner or later with an
additional field "starting offset". Possibly more fields to
enable identification. Sometimes it is really difficult to
determine which Linux name belongs to which hardware device,
especially with USB.

On the other hand, disk statistics should not be in
/proc/partitions. They should be in /proc/diskstatistics.
I see a heading today "rio rmerge rsect ruse wio wmerge"
"wsect wuse running use aveq". No doubt next year we'll
want different statistics. So /proc/diskstatistics should
start with a header line including a version field.

Please keep these disk statistics apart from /proc/partitions.

Andries

RE: IO stats in /proc/partitions

[M. Edward Borasky]

I'm with Andries on this one! Linux can't survive if anyone can change it
and break all the supporting software in user space that reads stuff from
/proc. I'm all in favor of expanded performance statistics on I/O - I look
at that stuff for a living and *write* some of those supporting tools. If I
have to recode my performance monitoring tools every time someone gets a
bright idea and doesn't personally e-mail me about it, I won't have the time
to do detailed performance analysis.

Linux has *got* to mature to the point where the documentation is *accurate*
and *available* and the APIs don't wobble under the feet of their users. I
recently spent a week trying to track down the units used for the disk stats
in /proc/stat. Through a combination of queries on the LKML and trucking
through the source with rgrep, I managed to get my questions answered. It
matters to me and to the people I work for exactly how many bytes the I/O
subsystem is handling per second, and how close to the capacity of the I/O
subsystem a machine is operating. I consider the fact that I had to dig for
and ask for this information unacceptable.

Maybe I've said this before, but it bears repeating for those in the Linux
community that are not in a business situation: business is about time,
people and money. Business people in general don't optimize, they
*satisfice*. That is, the overwhelming market share goes not to the *best*
product but to the one that is good enough and saves people time or makes
people money. Something that wastes my time costs my employer money.
--
M. Edward Borasky
znmeb@borasky-research.net

The COUGAR Project
http://www.borasky-research.com/Cougar.htm

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of
Andries.Brouwer@cwi.nl
Sent: Saturday, May 04, 2002 12:59 PM
To: alan@lxorguk.ukuu.org.uk; hpa@zytor.com; linux-kernel@vger.kernel.org;
marcelo@conectiva.com.br
Subject: Re: IO stats in /proc/partitions

Earlier I noticed that RedHat did put some statistics in
/proc/partitions. That was bad, but I assumed that it was
their laziness, being too busy to do a proper job.

However, I see that these days the pollution of /proc/partitions
is becoming official - it is part of patch-2.4.19-pre7.
I strongly object, and hope it is not too late to revert this.

Things must do one thing, and one thing well.
The task of /proc/partitions is to list which partitions the
kernel knows about. When I implemented it I thought that adding
the starting offset would be superfluous, but in fact I now realize
that that is required for several applications.
So, /proc/partitions must be updated sooner or later with an
additional field "starting offset". Possibly more fields to
enable identification. Sometimes it is really difficult to
determine which Linux name belongs to which hardware device,
especially with USB.

On the other hand, disk statistics should not be in
/proc/partitions. They should be in /proc/diskstatistics.
I see a heading today "rio rmerge rsect ruse wio wmerge"
"wsect wuse running use aveq". No doubt next year we'll
want different statistics. So /proc/diskstatistics should
start with a header line including a version field.

Please keep these disk statistics apart from /proc/partitions.

Andries

RE: IO stats in /proc/partitions

[Mark Hahn]

> I'm with Andries on this one! Linux can't survive if anyone can change it
> and break all the supporting software in user space that reads stuff from

there is no serious breakage issue, since the extra fields would
not break any competent parsing code.

> Linux has *got* to mature to the point where the documentation is *accurate*
> and *available* and the APIs don't wobble under the feet of their users. I

nah.  changing APIs and internals is exactly the reason Linux wins.

> subsystem a machine is operating. I consider the fact that I had to dig for
> and ask for this information unacceptable.

would you like that on a silver platter?

> people money. Something that wastes my time costs my employer money.

perhaps you've mistaken this for a Windows mailing list.

> On the other hand, disk statistics should not be in
> /proc/partitions. They should be in /proc/diskstatistics.

aesthetics is good, but here, what point would it serve?
tools would simply need to parse two separate files.
the point is that the files are inherently parallel.
if this aesthetic were followed, most of /proc would need to 
be transplanted into /system-info or something.  again,
serving no practical purpose.

RE: IO stats in /proc/partitions

[M. Edward (Ed) Borasky]

On Sat, 4 May 2002, Mark Hahn wrote:

> perhaps you've mistaken this for a Windows mailing list.

Well, it's Sunday in many parts of the world, so I will haul out my
soapbox and put on my flame-retardant jump-suit (penguin/tuxedo style,
of course :).

OK ... since you brought up Windows ... IMHO one of the things Windows
NT does *much* better than *any* UNIX, including Linux, is the
performance monitoring tools. First, you have a registry interface that
allows fetching of any counter by name, complete with an explanation of
what the counter means. I can pick this info up in Visual Basic, Visual
C++, C#, Java and even Perl. *And*, I can access these data over the
network from another system. The level of detail on things like disk I/O
is richer than most UNIX implementations.

Second, you have an API that allows an application developer to *easily*
add application-specific performance counters to the set that's
collected. And third, you have the PerfMon tool, which lets you capture
data in binary log files, graph data in real time, export data to
comma-separated value files for off-line analysis, and issue alerts when
a variable goes into a sysadmin-defined unacceptable range. In short,
Windows NT performance monitoring was *designed* -- it didn't *evolve*.

But design takes time ... and it isn't always as much fun as evolution.
So we performance engineers on the UNIX/Linux front build our own tools
-- sar, top, procinfo, iostat, vmstat, etc. -- and some of us, myself
among them, write code to parse their output or, in the case of Linux,
sometimes parse the files in /proc themselves. And we write R code to
plot the graphs that the techies and managers need to make capacity
planning decisions and solve performance issues for our users.

Yeah ...  it's a lot more fun than designing and implementing a
performance monitoring infrastructure like Windows has. It's also
frightfully inefficent to have the kernel do a "printf" on demand to
generate ASCII data, then open and read a bunch o' files in a humongous
Perl script and collect the samples in CSV format.
-- 
M. Edward Borasky
znmeb@borasky-research.net

The COUGAR Project
http://www.borasky-research.com/Cougar.htm

If I had 40 billion dollars for every software monopoly that sells an
unwieldy and hazardously complex development environment and is run by
an arrogant college dropout with delusions of grandeur who treats his
employees like serfs while he is acclaimed as a man of compelling
vision, I'd be a wealthy man.

Re: IO stats in /proc/partitions

[Jakob Østergaard]

On Sat, May 04, 2002 at 05:25:53PM -0400, Mark Hahn wrote:
> > I'm with Andries on this one! Linux can't survive if anyone can change it
> > and break all the supporting software in user space that reads stuff from
> 
> there is no serious breakage issue, since the extra fields would
> not break any competent parsing code.

That is ridiculous. Parsers parse a grammar, and fails when the input doesn't
obey the grammar.  Creating grammars that will satisfy *anything* that people
might think of putting into /proc files late saturday nights (take a look at
the ASCII art in /proc/mdstat for example !!) is not just something you can do
with any certainty.

You may think that you will be parsing a list of partitions - next week someone
felt that drawing a flowchart with ISO-8859-8 characters would be cooler, and
then you're stuck fixing your parser.

This was why we had a very long thread about creating an API for getting this
information out, something like kstat or pstat from some real 'NIX systems.

Let's not bring that thread up again - it's besides the point of this argument.
Read on.

> 
> > Linux has *got* to mature to the point where the documentation is *accurate*
> > and *available* and the APIs don't wobble under the feet of their users. I
> 
> nah.  changing APIs and internals is exactly the reason Linux wins.

No.  Changing APIs *when* and *where* it makes sense, is why Linux is winning.

There is a world of difference.

Disk statistics should *NOT* go into a partition-table-listing file.  Put the
statistics in a file for, say, *statistics*.    How hard can this be ?

It is
1)  Simple
2)  No more change than the original change
3)  Doesn't break parsers (neither the good or the bad ones)
4)  Logical.  Think of files as "name spaces", statistics in the statistics
    files, partitions in the partition files

What is the downside ?

Think about the BSD Socket API - sendfile() wasn't hacked into send() either. It could
have been - anything could have been hacked into send, but it was saner not to.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: IO stats in /proc/partitions

[Tomas Szepe]

> I recently spent a week trying to track down the units used for the disk stats
> in /proc/stat. Through a combination of queries on the LKML and trucking
> through the source with rgrep, I managed to get my questions answered. It
> matters to me and to the people I work for exactly how many bytes the I/O
> subsystem is handling per second, and how close to the capacity of the I/O
> subsystem a machine is operating. I consider the fact that I had to dig for
> and ask for this information unacceptable.

But hey, you've suffered thru it, which, guess what, makes you the perfect
candidate to have the honor of writing the docs!

Take care,
T.

Re: IO stats in /proc/partitions

[M. Edward (Ed) Borasky]

On Sat, 4 May 2002, Tomas Szepe wrote:

> But hey, you've suffered thru it, which, guess what, makes you the
> perfect candidate to have the honor of writing the docs!

The person who made the "design" decisions and implemented the code is
responsible for documenting it. At least that's what *I* was taught 40
years ago when I learned to program a computer.
-- 
M. Edward Borasky
znmeb@borasky-research.net

The COUGAR Project
http://www.borasky-research.com/Cougar.htm

How to Stop A Folksinger Cold # 4
"Tie me kangaroo down, sport..."
Tie your own kangaroo down -- and stop calling me "sport"!

Re: IO stats in /proc/partitions

[Mike Fedyk]

On Sat, May 04, 2002 at 06:08:58PM -0700, M. Edward (Ed) Borasky wrote:
> On Sat, 4 May 2002, Tomas Szepe wrote:
> 
> > But hey, you've suffered thru it, which, guess what, makes you the
> > perfect candidate to have the honor of writing the docs!
> 
> The person who made the "design" decisions and implemented the code is
> responsible for documenting it. At least that's what *I* was taught 40
> years ago when I learned to program a computer.

True, but we don't know if the code designer is still around to do so either.

By doing the code tracing yourself you are in a better position to submit
informed documentation patches.  This won't help the designer's habbits any,
but it'll help others in the position that you were in before you did the
tracing...

Re: IO stats in /proc/partitions

[Denis Vlasenko]

On 4 May 2002 19:35, Tomas Szepe wrote:
> > I recently spent a week trying to track down the units used for the disk
> > stats in /proc/stat. Through a combination of queries on the LKML and
> > trucking through the source with rgrep, I managed to get my questions
> > answered. It matters to me and to the people I work for exactly how many
> > bytes the I/O subsystem is handling per second, and how close to the
> > capacity of the I/O subsystem a machine is operating. I consider the fact
> > that I had to dig for and ask for this information unacceptable.
>
> But hey, you've suffered thru it, which, guess what, makes you the perfect
> candidate to have the honor of writing the docs!

And peppering code with cute little comments + feeding patches to Rusty's
'trivial' patchbot.

BTW, are units consistent? Kilobytes? Pages? Sectors?
--
vda

Re: IO stats in /proc/partitions

[M. Edward (Ed) Borasky]

On Sun, 5 May 2002, Denis Vlasenko wrote:

> And peppering code with cute little comments + feeding patches to Rusty's
> 'trivial' patchbot.
>
> BTW, are units consistent? Kilobytes? Pages? Sectors?

No. Here's a sample (2.2 kernel):

disk 25418854 0 0 0 <--- total "operations" = calls to a routine whose
name I've forgotten

disk_rio 6950521 0 0 0 <--- total reads = read calls to the routine

disk_wio 18468333 0 0 0 <--- total writes = write calls to the routine

disk_rblk 14410934 0 0 0 <--- total 512 byte "blocks" read

disk_wblk 37146264 0 0 0 <--- total 512 byte "blocks" written

page 30108037 50709997 <--- number of 1024 byte "pages" read and written
-- counted in another routine whose name I've forgotten

swap 532282 341062 <--- number of PAGESIZE chunks read and written to
swap space -- counted in yet another routine whose name I've forgotten.

The routine names are listed in a thread a few weeks back where I first
got these discoveries from someone who presumably had been down this
path before. I don't have a 2.4 kernel sample handy; the "disk" entries
changed to a bizarre format that required a whole new parser in my code
and some complicated logic to figure out whether it was dealing with 2.2
or 2.4 :(.

As you can probably guess, this sort of thing is one of the issues that
my "COUGAR" proposal corrects. I leave design issues to the designers,
but one thing I insist on is that there *be* requirements --
*documented* requirements -- and a *documented* and debated design
*before* hacking the code into the kernel and making implementation
decisions.

Of course, since I would be the designer of at least part of "COUGAR", I
would be making some of those decisions. Unfortunately, I have limited
time to work on "COUGAR" until maybe late July, so if someone wants to
pick up some of the balls and run with them, I'm willing to unload them.
(Apologies if my metaphor jars those of you who live where football is
played without the use of hands :).

This is a process I highly recommend for performance-determining parts
of Linux, like memory management and the scheduler. I know the memory
management and scheduler gurus -- Rik, Andrea, Ingo and others -- *have*
designs in their heads, *have* requirements that they're working to -- I
just think we should be sharing and debating *those* on the list instead
of just code and benchmark results.

-- 
M. Edward Borasky
znmeb@borasky-research.net

The COUGAR Project
http://www.borasky-research.com/Cougar.htm

Re: IO stats in /proc/partitions

[Thomas Zimmerman]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

On 05-May 11:10, M. Edward (Ed) Borasky wrote:
> On Sun, 5 May 2002, Denis Vlasenko wrote:
> 
[snip] 
> As you can probably guess, this sort of thing is one of the issues that
> my "COUGAR" proposal corrects. I leave design issues to the designers,
> but one thing I insist on is that there *be* requirements --
> *documented* requirements -- and a *documented* and debated design
> *before* hacking the code into the kernel and making implementation
> decisions.

...and here is where you sliped the track. Linux is designed by those
who post patches and lobby for thier use. If something doesn't work for
you post *patches* that fix it. Complaints that you don't have time to
work around current code gets you nothing. 

As far as I can see, the reason that staticis now live in 
/proc/partitions is that there was code _submitted_ (the sar patches) 
to collect the staticis. If you have a better patch I, for one, would 
love to see it. I don't think IO statistics shareing /proc/partitons 
is great *design* but it was thought it would break the least tools 
out there. 
> 
> Of course, since I would be the designer of at least part of "COUGAR", I
> would be making some of those decisions. Unfortunately, I have limited
> time to work on "COUGAR" until maybe late July, so if someone wants to
> pick up some of the balls and run with them, I'm willing to unload them.
> (Apologies if my metaphor jars those of you who live where football is
> played without the use of hands :).
> 
> This is a process I highly recommend for performance-determining parts
> of Linux, like memory management and the scheduler. I know the memory
> management and scheduler gurus -- Rik, Andrea, Ingo and others -- *have*
> designs in their heads, *have* requirements that they're working to -- I
> just think we should be sharing and debating *those* on the list instead
> of just code and benchmark results.

Everyone loves the debate, but if no code is ever show all we get out of
it _is_ the debate. How many times has this happened on this subject
(widely taken as the /proc/* debate)? I've seen lots of hot air, but
little code.

Just my take,
Thomas Zimmerman

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: IO stats in /proc/partitions

[Alan Cox]

> Earlier I noticed that RedHat did put some statistics in
> /proc/partitions. That was bad, but I assumed that it was
> their laziness, being too busy to do a proper job.

It was put there in the 2.2 era after discussion with various folks. Its
been in most vendor kernels for about four years.

> On the other hand, disk statistics should not be in
> /proc/partitions. They should be in /proc/diskstatistics.
> I see a heading today "rio rmerge rsect ruse wio wmerge"
> "wsect wuse running use aveq". No doubt next year we'll
> want different statistics. So /proc/diskstatistics should
> start with a header line including a version field.

The stats have been unchanged for years too. As to version lines 
why ? This is lets mke /proc XML hell again

> Please keep these disk statistics apart from /proc/partitions.

It has to contain each partiiton anyway. 

Re: IO stats in /proc/partitions

[H. Peter Anvin]

Alan Cox wrote:
>>Earlier I noticed that RedHat did put some statistics in
>>/proc/partitions. That was bad, but I assumed that it was
>>their laziness, being too busy to do a proper job.
> 
> It was put there in the 2.2 era after discussion with various folks. Its
> been in most vendor kernels for about four years.
> 
>>On the other hand, disk statistics should not be in
>>/proc/partitions. They should be in /proc/diskstatistics.
>>I see a heading today "rio rmerge rsect ruse wio wmerge"
>>"wsect wuse running use aveq". No doubt next year we'll
>>want different statistics. So /proc/diskstatistics should
>>start with a header line including a version field.
> 
> The stats have been unchanged for years too. As to version lines 
> why ? This is lets mke /proc XML hell again
> 
>>Please keep these disk statistics apart from /proc/partitions.
> 
> It has to contain each partiiton anyway. 

If we're going to add stuff to /proc/partitions, I'd really like to see 
it contain: a) parent device, and b) offset.

	-hpa

Re: IO stats in /proc/partitions

[Marcelo Tosatti]

On Sat, 4 May 2002 Andries.Brouwer@cwi.nl wrote:

> Earlier I noticed that RedHat did put some statistics in
> /proc/partitions. That was bad, but I assumed that it was
> their laziness, being too busy to do a proper job.
> 
> However, I see that these days the pollution of /proc/partitions
> is becoming official - it is part of patch-2.4.19-pre7.
> I strongly object, and hope it is not too late to revert this.
> 
> Things must do one thing, and one thing well.
> The task of /proc/partitions is to list which partitions the
> kernel knows about. When I implemented it I thought that adding
> the starting offset would be superfluous, but in fact I now realize
> that that is required for several applications.
> So, /proc/partitions must be updated sooner or later with an
> additional field "starting offset". Possibly more fields to
> enable identification. Sometimes it is really difficult to
> determine which Linux name belongs to which hardware device,
> especially with USB.
> 
> On the other hand, disk statistics should not be in
> /proc/partitions. They should be in /proc/diskstatistics.
> I see a heading today "rio rmerge rsect ruse wio wmerge"
> "wsect wuse running use aveq". No doubt next year we'll
> want different statistics. So /proc/diskstatistics should
> start with a header line including a version field.
> 
> Please keep these disk statistics apart from /proc/partitions.

The change can possibly break userlevel tools which were working with
2.4.18.

Christoph, please create a /proc/diskstatistics file or something like
that and send me a patch.

Thanks.

Re: IO stats in /proc/partitions

[Miquel van Smoorenburg]

In article <Pine.LNX.4.21.0205151838001.21222-100000@freak.distro.conectiva>,
Marcelo Tosatti  <marcelo@conectiva.com.br> wrote:
>On Sat, 4 May 2002 Andries.Brouwer@cwi.nl wrote:
>
>> However, I see that these days the pollution of /proc/partitions
>> is becoming official - it is part of patch-2.4.19-pre7.
>> I strongly object, and hope it is not too late to revert this.
>> 
>The change can possibly break userlevel tools which were working with
>2.4.18.

Perhaps, but I had the opposite experience. I noticed by accident
that iostat (as included in Debian) suddenly had working extended
statistics. So there are *certainly* tools that get fixed by
2.4.19-pre7. I was pleasantly surprised.

>Christoph, please create a /proc/diskstatistics file or something like
>that and send me a patch.

Bummer, I'm using Debian, and iostat is in woody (frozen, about to
be released) - that means Debian users will have to wait to the
next release, another two years perhaps, before iostat gets working.

Why not keep it as it is, it's probably not going to break
anything as debian and redhat tools already know about this
apparently. 2.5 is about new features, 2.4 is about stability
and, though some might oppose, folding in stable patches that
have been in vendor kernels for months or years.

Mike.
-- 
"Insanity -- a perfectly rational adjustment to an insane world."
  - R.D. Lang

Re: IO stats in /proc/partitions

[Alan Cox]

> Perhaps, but I had the opposite experience. I noticed by accident
> that iostat (as included in Debian) suddenly had working extended
> statistics. So there are *certainly* tools that get fixed by
> 2.4.19-pre7. I was pleasantly surprised.

Pretty much every vendor shipped the /proc/partitions changes and
has tools that will look for them. Its annoying to change stuff but
long term /proc/partitions is the wrong place for disk stats

Re: IO stats in /proc/partitions

[Bill Davidsen]

On Thu, 16 May 2002, Alan Cox wrote:

> > Perhaps, but I had the opposite experience. I noticed by accident
> > that iostat (as included in Debian) suddenly had working extended
> > statistics. So there are *certainly* tools that get fixed by
> > 2.4.19-pre7. I was pleasantly surprised.
> 
> Pretty much every vendor shipped the /proc/partitions changes and
> has tools that will look for them. Its annoying to change stuff but
> long term /proc/partitions is the wrong place for disk stats

  Changes belong in 2.5, /proc/partitions is the wrong place, but it's
also the place the tools expect. I hope that's not going to change in the
stable kernel.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: IO stats in /proc/partitions

[Guest section DW]

On Mon, May 20, 2002 at 02:19:48PM -0400, Bill Davidsen wrote:
> On Thu, 16 May 2002, Alan Cox wrote:

> > Pretty much every vendor shipped the /proc/partitions changes and
> > has tools that will look for them. Its annoying to change stuff but
> > long term /proc/partitions is the wrong place for disk stats

>   Changes belong in 2.5, /proc/partitions is the wrong place, but it's
> also the place the tools expect. I hope that's not going to change in the
> stable kernel.

You misunderstand.
Everybody agrees that /proc/partitions is the wrong place.
Up to now these statistics have not been part of any official
kernel, stable or not.
However, someone wanted to introduce them for the first time
in 2.4.19 and put them in /proc/partitions. That is a really bad idea,
especially when they will be somewhere else in 2.5.

Andries

Re: IO stats in /proc/partitions

[Alan Cox]

> >   Changes belong in 2.5, /proc/partitions is the wrong place, but it's
> > also the place the tools expect. I hope that's not going to change in the
> > stable kernel.
> 
> You misunderstand.
> Everybody agrees that /proc/partitions is the wrong place.
> Up to now these statistics have not been part of any official
> kernel, stable or not.

The 2.4 stable kernel is the minority product here 8)

> However, someone wanted to introduce them for the first time
> in 2.4.19 and put them in /proc/partitions. That is a really bad idea,
> especially when they will be somewhere else in 2.5.

I agree. Its relatively easy for vendors to keep the stats in /proc/partitions
for 2.4.x (certainly adding other stuff instead to proc/partitions for 2.4
is bad). It is better that people are encouraged to use a new 2.5 compatible
interface over time and for later 2.4.x that vendors ship something with
both.

Alan

Re: IO stats in /proc/partitions

[Christoph Hellwig]

On Wed, May 15, 2002 at 06:39:03PM -0300, Marcelo Tosatti wrote:
> > On the other hand, disk statistics should not be in
> > /proc/partitions. They should be in /proc/diskstatistics.
> > I see a heading today "rio rmerge rsect ruse wio wmerge"
> > "wsect wuse running use aveq". No doubt next year we'll
> > want different statistics. So /proc/diskstatistics should
> > start with a header line including a version field.
> > 
> > Please keep these disk statistics apart from /proc/partitions.
> 
> The change can possibly break userlevel tools which were working with
> 2.4.18.
> 
> Christoph, please create a /proc/diskstatistics file or something like
> that and send me a patch.

I rather send a complete backout patch for mainline instead.  This format
has been used by the vendor (Red Hat, SuSE, etc..) kernels since 2.2 ages
and is used (if present) by the stock performance tools for linux
(i.e. syststat package, iostat).

Re: IO stats in /proc/partitions

[Marcelo Tosatti]

On Thu, 16 May 2002, Christoph Hellwig wrote:

> On Wed, May 15, 2002 at 06:39:03PM -0300, Marcelo Tosatti wrote:
> > > On the other hand, disk statistics should not be in
> > > /proc/partitions. They should be in /proc/diskstatistics.
> > > I see a heading today "rio rmerge rsect ruse wio wmerge"
> > > "wsect wuse running use aveq". No doubt next year we'll
> > > want different statistics. So /proc/diskstatistics should
> > > start with a header line including a version field.
> > > 
> > > Please keep these disk statistics apart from /proc/partitions.
> > 
> > The change can possibly break userlevel tools which were working with
> > 2.4.18.
> > 
> > Christoph, please create a /proc/diskstatistics file or something like
> > that and send me a patch.
> 
> I rather send a complete backout patch for mainline instead.  This format
> has been used by the vendor (Red Hat, SuSE, etc..) kernels since 2.2 ages
> and is used (if present) by the stock performance tools for linux
> (i.e. syststat package, iostats

Look, I just do not want to break some apps which read /proc/partitions.
Thats it.

Look, changing the userlevel apps to at least know about the new format is
not hard. And you can do that over time.

Do you see why I think /proc/whatever-else is interesting ?

Re: IO stats in /proc/partitions

[Christoph Hellwig]

On Thu, May 23, 2002 at 05:27:13PM -0300, Marcelo Tosatti wrote:
> > I rather send a complete backout patch for mainline instead.  This format
> > has been used by the vendor (Red Hat, SuSE, etc..) kernels since 2.2 ages
> > and is used (if present) by the stock performance tools for linux
> > (i.e. syststat package, iostats
> 
> Look, I just do not want to break some apps which read /proc/partitions.
> Thats it.

Umm, thos apps would have broken on any stock Red Hat/SuSE/Mandrake
installation of the last years!

> Look, changing the userlevel apps to at least know about the new format is
> not hard. And you can do that over time.

Well, the stock sysstat util works with this format now with the vendor
kernels, recent -ac and 2.4.19-pre.  If you don't want this I can send
a backout patch - again only people using vendor kernel or maybe -ac
will have that feature.  No big point.

Re: IO stats in /proc/partitions

[Nivedita Singhvi]

>> But hey, you've suffered thru it, which, guess what, makes you the
>> perfect candidate to have the honor of writing the docs!

> The person who made the "design" decisions and implemented the code is
> responsible for documenting it. At least that's what *I* was taught 40
> years ago when I learned to program a computer.
> --
> M. Edward Borasky

Ed, this is Linux and open source.   It is where it is today because of
cooperation,  contribution and generous understanding.
People contribute what they can, and they're not necessarily
getting paid to do so.  If its valuable to others, it gets
used.  The way I see it, getting anything at all is a bonus.

Additionally, not all  developers who contribute to Linux live in the US
and speak English.  I'm guessing that documentation in Russian or
Marathi wouldn't be much use to you..

Just something to think about..

thanks,
Nivedita

IO stats in /proc/partitions

[Jean-Eric Cuendet]

Hi,
I use 2.4.19-pre2-ac4.
2 questions:
- Either MD Raid ot LVM IO devices are not accounted in /proc/partitions 
IO data. Is it normal?
- Are the new /proc/partitions IO stats integrated in 2.4.19-pre3?

Bye
-jec

-- 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
E-mail: jean-eric.cuendet@linkvest.com
http://www.linkvest.com
--------------------------------------------------------

Re: IO stats in /proc/partitions

[H. Peter Anvin]

Followup to:  <3C8E1FFF.9090705@linkvest.com>
By author:    Jean-Eric Cuendet <jean-eric.cuendet@linkvest.com>
In newsgroup: linux.dev.kernel
>
> Hi,
> I use 2.4.19-pre2-ac4.
> 2 questions:
> - Either MD Raid ot LVM IO devices are not accounted in /proc/partitions 
> IO data. Is it normal?
> - Are the new /proc/partitions IO stats integrated in 2.4.19-pre3?
> 

If we're adding fields to /proc/partitions, I would like to
*strongly* recommend that /proc/partitions adds the following
information:

	offset and length
	parent device (if applicable)

The latter could also be used to identify parallelizable devices
(spindles) for things like fsck.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: IO stats in /proc/partitions

[Anton Altaparmakov]

At 21:51 12/03/02, H. Peter Anvin wrote:
>Followup to:  <3C8E1FFF.9090705@linkvest.com>
>By author:    Jean-Eric Cuendet <jean-eric.cuendet@linkvest.com>
>In newsgroup: linux.dev.kernel
> >
> > Hi,
> > I use 2.4.19-pre2-ac4.
> > 2 questions:
> > - Either MD Raid ot LVM IO devices are not accounted in /proc/partitions
> > IO data. Is it normal?
> > - Are the new /proc/partitions IO stats integrated in 2.4.19-pre3?
> >
>
>If we're adding fields to /proc/partitions, I would like to
>*strongly* recommend that /proc/partitions adds the following
>information:
>
>         offset and length

I had a patch for this already. I can update it and resend if the powers 
that be want it. Just let me know...

Anton

>         parent device (if applicable)
>
>The latter could also be used to identify parallelizable devices
>(spindles) for things like fsck.
>
>         -hpa
>--
><hpa@transmeta.com> at work, <hpa@zytor.com> in private!
>"Unix gives you enough rope to shoot yourself in the foot."
>http://www.zytor.com/~hpa/puzzle.txt    <amsp@zytor.com>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/