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 {
On Wed, Sep 29, 2004 at 11:13:45AM -0500, [email protected] 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.
> On Wed, Sep 29, 2004 at 11:13:45AM -0500, [email protected] 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.
>
>
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 ...
-----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:[email protected]
*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-----
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
> 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:[email protected]
> *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-----
>
>
[email protected] 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 [email protected]
> 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.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
> [email protected] 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 [email protected]
> > 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.
> *[email protected]
> *gpg keyid: 1024D / 0x92A74FA1
> *http://pgp.mit.edu
> ***************************************************/
>
Miller, Mike (OS Dev) wrote:
>>[email protected] 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 [email protected]
>>>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.
>> *[email protected]
>> *gpg keyid: 1024D / 0x92A74FA1
>> *http://pgp.mit.edu
>> ***************************************************/
>
>
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
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, [email protected] 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.
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
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