patch so cciss stats are collected in /proc/stat

patch so cciss stats are collected in /proc/stat

[mike.miller]

Currently cciss statistics are not collected in /proc/stat. This patch
bumps DK_MAX_MAJOR to 111 to fix that. This has been a common complaint
by customers wishing to gather info about cciss devices.
Please consider this for inclusion. Applies to 2.4.28-pre3.

Thanks,
mikem
-------------------------------------------------------------------------------

diff -burNp lx2428-pre1.orig/include/linux/kernel_stat.h lx2428-pre1/include/linux/kernel_stat.h
--- lx2428-pre1.orig/include/linux/kernel_stat.h	2004-08-23 15:41:43.640300000 -0500
+++ lx2428-pre1/include/linux/kernel_stat.h	2004-08-23 15:43:07.097613064 -0500
@@ -12,7 +12,7 @@
  * used by rstatd/perfmeter
  */
 
-#define DK_MAX_MAJOR 16
+#define DK_MAX_MAJOR 111
 #define DK_MAX_DISK 16
 
 struct kernel_stat {

Re: patch so cciss stats are collected in /proc/stat

[Christoph Hellwig]

On Wed, Sep 29, 2004 at 11:13:45AM -0500, mike.miller@hp.com wrote:
> Currently cciss statistics are not collected in /proc/stat. This patch
> bumps DK_MAX_MAJOR to 111 to fix that. This has been a common complaint
> by customers wishing to gather info about cciss devices.
> Please consider this for inclusion. Applies to 2.4.28-pre3.

This patch has been reject about half a million times, why are people
submitting it again and again?

You get more detailed statistics in /proc/partitions.

RE: patch so cciss stats are collected in /proc/stat

[Miller, Mike (OS Dev)]

> On Wed, Sep 29, 2004 at 11:13:45AM -0500, mike.miller@hp.com wrote:
> > Currently cciss statistics are not collected in /proc/stat. 
> This patch
> > bumps DK_MAX_MAJOR to 111 to fix that. This has been a 
> common complaint
> > by customers wishing to gather info about cciss devices.
> > Please consider this for inclusion. Applies to 2.4.28-pre3.
> 
> This patch has been reject about half a million times, why are people
> submitting it again and again?

As I said in my mail, it's a customer driven issue. As long as customers rely on /proc/stat we'll keep trying. You can't tell a customer how he/she should be doing things on their systems.

mikem
> 
> You get more detailed statistics in /proc/partitions.
> 
> 

RE: patch so cciss stats are collected in /proc/stat

[Arjan van de Ven]

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

On Wed, 2004-09-29 at 18:29, Miller, Mike (OS Dev) wrote:

> > This patch has been reject about half a million times, why are people
> > submitting it again and again?
> 
> As I said in my mail, it's a customer driven issue. As long as customers rely on /proc/stat we'll keep trying. You can't tell a customer how he/she should be doing things on their systems.

I doubt you have many customers using 2.4.28.... I suspect that by now
the majority of people is either using an (ancient) 2.4 vendor kernel or
a 2.6 kernel. The very low number of reports on lkml about 2.4 seems to
confirm that ...

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: patch so cciss stats are collected in /proc/stat

[Andreas Haumer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjan van de Ven wrote:
> On Wed, 2004-09-29 at 18:29, Miller, Mike (OS Dev) wrote:
>
>
>>>This patch has been reject about half a million times, why are people
>>>submitting it again and again?
>>
>>As I said in my mail, it's a customer driven issue. As long as customers rely on /proc/stat we'll keep trying. You can't tell a customer how he/she should be doing things on their systems.
>
>
> I doubt you have many customers using 2.4.28.... I suspect that by now
> the majority of people is either using an (ancient) 2.4 vendor kernel or
> a 2.6 kernel. The very low number of reports on lkml about 2.4 seems to
> confirm that ...

"25% of accidents are caused by drunken drivers. That means
75% of accidents are caused by drivers which did not drink.
So why keep people complaining about alcohol and driving?"

Is that what you mean? You must be kidding!

The majority of _our_ customers are using 2.4.x kernels
(x beeing in the range from 19 to 28pre3) and it looks like
it will stay that for quite a while...

- - andreas

PS: I know this is somewhat off topic, but I just want to raise
my voice if I get the impression kernel developers forget about
the "real world outside". I will shut up in a moment! Thank you!

- --
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBWum9xJmyeGcXPhERArzMAKCYhHvVvwpFObCzrPby2qY9u9MURQCgrelJ
BpeZ2tG8zw0po/5ByYKFuZk=
=RlQc
-----END PGP SIGNATURE-----

Re: patch so cciss stats are collected in /proc/stat

[mikem]

On Wed, Sep 29, 2004 at 06:43:06PM +0200, Arjan van de Ven wrote:
> On Wed, 2004-09-29 at 18:29, Miller, Mike (OS Dev) wrote:
> 
> > > This patch has been reject about half a million times, why are people
> > > submitting it again and again?
> > 
> > As I said in my mail, it's a customer driven issue. As long as customers rely on /proc/stat we'll keep trying. You can't tell a customer how he/she should be doing things on their systems.
> 
> I doubt you have many customers using 2.4.28.... I suspect that by now
> the majority of people is either using an (ancient) 2.4 vendor kernel or
> a 2.6 kernel. The very low number of reports on lkml about 2.4 seems to
> confirm that ...

Obviously no one is using 2.4.28 yet, but it's pretty hard to update the ancient kernels. I've also submitted patches to our partners to fix this in their distros.

mikem

RE: patch so cciss stats are collected in /proc/stat

[Miller, Mike (OS Dev)]

> Arjan van de Ven wrote:
> > On Wed, 2004-09-29 at 18:29, Miller, Mike (OS Dev) wrote:
> >
> >
> >>>This patch has been reject about half a million times, why 
> are people
> >>>submitting it again and again?
> >>
> >>As I said in my mail, it's a customer driven issue. As long 
> as customers rely on /proc/stat we'll keep trying. You can't 
> tell a customer how he/she should be doing things on their systems.
> >
> >
> > I doubt you have many customers using 2.4.28.... I suspect 
> that by now
> > the majority of people is either using an (ancient) 2.4 
> vendor kernel or
> > a 2.6 kernel. The very low number of reports on lkml about 
> 2.4 seems to
> > confirm that ...
> 
> "25% of accidents are caused by drunken drivers. That means
> 75% of accidents are caused by drivers which did not drink.
> So why keep people complaining about alcohol and driving?"
> 
> Is that what you mean? You must be kidding!
> 
> The majority of _our_ customers are using 2.4.x kernels
> (x beeing in the range from 19 to 28pre3) and it looks like
> it will stay that for quite a while...
> 
> - - andreas
> 
> PS: I know this is somewhat off topic, but I just want to raise
> my voice if I get the impression kernel developers forget about
> the "real world outside". I will shut up in a moment! Thank you!

Thank you, Andreas. I forgot to mention that very salient point!

mikem

> 
> - --
> Andreas Haumer                     | mailto:andreas@xss.co.at
> *x Software + Systeme              | http://www.xss.co.at/
> Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
> A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFBWum9xJmyeGcXPhERArzMAKCYhHvVvwpFObCzrPby2qY9u9MURQCgrelJ
> BpeZ2tG8zw0po/5ByYKFuZk=
> =RlQc
> -----END PGP SIGNATURE-----
> 
> 

Re: patch so cciss stats are collected in /proc/stat

[Neil Horman]

mike.miller@hp.com wrote:
> Currently cciss statistics are not collected in /proc/stat. This patch
> bumps DK_MAX_MAJOR to 111 to fix that. This has been a common complaint
> by customers wishing to gather info about cciss devices.
> Please consider this for inclusion. Applies to 2.4.28-pre3.
> 
> Thanks,
> mikem
> -------------------------------------------------------------------------------
> 
> diff -burNp lx2428-pre1.orig/include/linux/kernel_stat.h lx2428-pre1/include/linux/kernel_stat.h
> --- lx2428-pre1.orig/include/linux/kernel_stat.h	2004-08-23 15:41:43.640300000 -0500
> +++ lx2428-pre1/include/linux/kernel_stat.h	2004-08-23 15:43:07.097613064 -0500
> @@ -12,7 +12,7 @@
>   * used by rstatd/perfmeter
>   */
>  
> -#define DK_MAX_MAJOR 16
> +#define DK_MAX_MAJOR 111
>  #define DK_MAX_DISK 16
>  
>  struct kernel_stat {
> -
> 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/
The answer to this is to use the latest sysstat tools.  the latest 
version of iostat, sar, etc draw information out of /proc/partitions 
rather than out of /proc/stat.  Or are you using some other home rolled 
tool in this case?

Neil

-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

RE: patch so cciss stats are collected in /proc/stat

[Miller, Mike (OS Dev)]

> mike.miller@hp.com wrote:
> > Currently cciss statistics are not collected in /proc/stat. 
> This patch
> > bumps DK_MAX_MAJOR to 111 to fix that. This has been a 
> common complaint
> > by customers wishing to gather info about cciss devices.
> > Please consider this for inclusion. Applies to 2.4.28-pre3.
> > 
> > Thanks,
> > mikem
> > 
> --------------------------------------------------------------
> -----------------
> > 
> > diff -burNp lx2428-pre1.orig/include/linux/kernel_stat.h 
> lx2428-pre1/include/linux/kernel_stat.h
> > --- lx2428-pre1.orig/include/linux/kernel_stat.h	
> 2004-08-23 15:41:43.640300000 -0500
> > +++ lx2428-pre1/include/linux/kernel_stat.h	2004-08-23 
> 15:43:07.097613064 -0500
> > @@ -12,7 +12,7 @@
> >   * used by rstatd/perfmeter
> >   */
> >  
> > -#define DK_MAX_MAJOR 16
> > +#define DK_MAX_MAJOR 111
> >  #define DK_MAX_DISK 16
> >  
> >  struct kernel_stat {
> > -
> > 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/
> The answer to this is to use the latest sysstat tools.  the latest 
> version of iostat, sar, etc draw information out of /proc/partitions 
> rather than out of /proc/stat.  Or are you using some other 
> home rolled 
> tool in this case?
> 
> Neil

It's customers that are doing this. I think some of them are using their own tools. Others are probably using whatever comes on their distro.

mikem

> 
> -- 
> /***************************************************
>   *Neil Horman
>   *Software Engineer
>   *Red Hat, Inc.
>   *nhorman@redhat.com
>   *gpg keyid: 1024D / 0x92A74FA1
>   *http://pgp.mit.edu
>   ***************************************************/
> 

Re: patch so cciss stats are collected in /proc/stat

[Neil Horman]

Miller, Mike (OS Dev) wrote:
>>mike.miller@hp.com wrote:
>>
>>>Currently cciss statistics are not collected in /proc/stat. 
>>
>>This patch
>>
>>>bumps DK_MAX_MAJOR to 111 to fix that. This has been a 
>>
>>common complaint
>>
>>>by customers wishing to gather info about cciss devices.
>>>Please consider this for inclusion. Applies to 2.4.28-pre3.
>>>
>>>Thanks,
>>>mikem
>>>
>>
>>--------------------------------------------------------------
>>-----------------
>>
>>>diff -burNp lx2428-pre1.orig/include/linux/kernel_stat.h 
>>
>>lx2428-pre1/include/linux/kernel_stat.h
>>
>>>--- lx2428-pre1.orig/include/linux/kernel_stat.h	
>>
>>2004-08-23 15:41:43.640300000 -0500
>>
>>>+++ lx2428-pre1/include/linux/kernel_stat.h	2004-08-23 
>>
>>15:43:07.097613064 -0500
>>
>>>@@ -12,7 +12,7 @@
>>>  * used by rstatd/perfmeter
>>>  */
>>> 
>>>-#define DK_MAX_MAJOR 16
>>>+#define DK_MAX_MAJOR 111
>>> #define DK_MAX_DISK 16
>>> 
>>> struct kernel_stat {
>>>-
>>>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/
>>
>>The answer to this is to use the latest sysstat tools.  the latest 
>>version of iostat, sar, etc draw information out of /proc/partitions 
>>rather than out of /proc/stat.  Or are you using some other 
>>home rolled 
>>tool in this case?
>>
>>Neil
> 
> 
> It's customers that are doing this. I think some of them are using their own tools. Others are probably using whatever comes on their distro.
> 
> mikem
> 
They should probably upgrade their tools, be they from the distro or 
their own (It was my understanding that /proc/stat was depricated and 
going to be removed in the not-to-distant future).

Neil

> 
>>-- 
>>/***************************************************
>>  *Neil Horman
>>  *Software Engineer
>>  *Red Hat, Inc.
>>  *nhorman@redhat.com
>>  *gpg keyid: 1024D / 0x92A74FA1
>>  *http://pgp.mit.edu
>>  ***************************************************/
> 
> 


-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

Re: patch so cciss stats are collected in /proc/stat

[Marcelo Tosatti]

On Wed, Sep 29, 2004 at 11:29:59AM -0500, Miller, Mike (OS Dev) wrote:
> 
> > On Wed, Sep 29, 2004 at 11:13:45AM -0500, mike.miller@hp.com wrote:
> > > Currently cciss statistics are not collected in /proc/stat. 
> > This patch
> > > bumps DK_MAX_MAJOR to 111 to fix that. This has been a 
> > common complaint
> > > by customers wishing to gather info about cciss devices.
> > > Please consider this for inclusion. Applies to 2.4.28-pre3.
> > 
> > This patch has been reject about half a million times, why are people
> > submitting it again and again?
> 
> As I said in my mail, it's a customer driven issue. As long as customers rely on /proc/stat we'll keep trying. You can't tell a customer how he/she should be doing things on their systems.

Mike, 

I dont like the patch either.

If you can have the same statistics through /proc/partitions 
(do I get this right?) just tell that to users.

Re: patch so cciss stats are collected in /proc/stat

[Willy Tarreau]

On Wed, Sep 29, 2004 at 06:58:55PM +0200, Andreas Haumer wrote:
> The majority of _our_ customers are using 2.4.x kernels
> (x beeing in the range from 19 to 28pre3) and it looks like
> it will stay that for quite a while...

I second this. The only one of our customers who tried 2.6 went back to
2.4 because of poor network performance, scheduling problems and stability
issues.

> PS: I know this is somewhat off topic, but I just want to raise
> my voice if I get the impression kernel developers forget about
> the "real world outside". I will shut up in a moment! Thank you!

Very true. You just have to read any 2.6 changelog to understand that
it *is* a development kernel ! The difference between 2.5 and 2.6 is
that the test platform now is larger and includes production systems.

Willy

Re: patch so cciss stats are collected in /proc/stat

[Willy Tarreau]

On Wed, Sep 29, 2004 at 06:43:06PM +0200, Arjan van de Ven wrote:
> I doubt you have many customers using 2.4.28.... I suspect that by now
> the majority of people is either using an (ancient) 2.4 vendor kernel or
> a 2.6 kernel. The very low number of reports on lkml about 2.4 seems to
> confirm that ...

You must be kidding, aren't you ? I would better say that the very high
number of reports on lkml about 2.6 seems to confirm that 2.6 still is
a toy !

Marcelo has done a great job at getting 2.4 stable, and now people are
installing it in remote locations or embedded system with no planned
updated at all. And it works. Just like people did with 2.0 recently.
This may be why there are so few reports.

Willy