From: Tony.Young@ir.com
To: Don.Dupuis@COMPAQ.com, linux-kernel@vger.kernel.org
Subject: RE: /proc/stat disk_io entries
Date: Mon, 26 Mar 2001 10:14:47 +1000 [thread overview]
Message-ID: <C0D2F5944500D411AD8A00104B31930E8D3CB7@ir_nt_server2> (raw)
The structure tables size is a concern for me too. Hence the suggestion that
perhaps a hash table implementationg is better suited to the job. The larger
sizes that you need for your Array seem to bear this out. Until a fix is
implemented I'm just going to modify DK_MAX_MAJOR to fix my own
requirements.
> -----Original Message-----
> From: Dupuis, Don [mailto:Don.Dupuis@COMPAQ.com]
> Sent: Saturday, 24 March 2001 02:02
> To: Tony Young; linux-kernel@vger.kernel.org
> Subject: RE: /proc/stat disk_io entries
>
>
> I have sent a patch to Alan and Linus about this also. We
> have cpqarray and
> cciss controllers that use major 72-79 and 104-111. Alan
> said he doesn't
> have time to look at it till mid April and Linus hasn't
> responded to me at
> all about it. The best way is to actually rewrite the kstat
> architecture,
> but the patch I sent it will do the job. There is concern
> about structure
> table size I believe. My patch increased DK_MAX_MAJOR to 112
> and added
> about 4 lines to genhd.h to support the cpqarray and cciss
> driver. This
> works on Compaq servers and I get the data that is needed.
> Any thoughts?
>
> -----Original Message-----
> From: Tony.Young@ir.com [mailto:Tony.Young@ir.com]
> Sent: Thursday, March 22, 2001 9:55 PM
> To: linux-kernel@vger.kernel.org
> Subject: /proc/stat disk_io entries
>
>
> All,
>
> Firstly, my relevant system stats:
> kernel linux 2.4.3-pre6
> hda IDE Drive
> hdb CD drive
> hdc IDE Drive
> hdd IDE Drive
> sda SCSI Drive
>
> The problem I'm seeing is that IO stats (disk_io) aren't
> being shown in
> /proc/stats for the 2 harddrives on the second ide controller
> (hdc and hdd).
>
> I checked the kernel code and found the function kstat_read_proc in
> fs/proc/proc_misc.c which loops through from 0 up to
> DK_MAX_MAJOR and prints
> out the stats to /proc/stat for each drive. However,
> DK_MAX_MAJOR is set to
> 16 in include/linux/kernel_stat.h, which means that the
> drives on my second
> ide controller, with a major number of 22, aren't included in
> the loop.
>
> I modified the value of DK_MAX_MAJOR to 23 and rebuilt and
> /proc/stats now
> shows the 2 missing harddrives. I'm uncomfortable sending in
> a patch for
> this as I'm not familiar enough with the code to understand the full
> ramifications of changing this value. Considering also that
> the value 23
> stills doesn't include any tertiary or quaternary ide
> controllers (33 and
> 34) makes me wonder what the correct value should really be.
>
> I'm also curious, after considering the above, about whether
> or not a hash
> table(s) would be better suited to the current implementation of
> 2-dimensional arrays for disk stats (dk_drive, dk_drive_rio,
> dk_drive_wio,
> etc).
>
> I've brought this to the list because I'm not sure of the
> correct solution
> and I couldn't work out if there was a specific maintainer of
> this code.
>
> It also seems strange to me that the identifiers for the
> values for disk_io
> in /proc/stat are (major_number,disk_number) tuples rather than
> (major,minor). The current implementation with my change now
> shows my first
> ide drive to be identified as (8,0), while my second and
> third ide drives
> (hdc and hdd) are identified as (22,2) and (22,3)
> respectively rather than
> (22,0) and (22,1) - I presume because they are the in the 3rd
> and 4th ide
> positions. Using disk_number instead of minor number also
> makes it more
> difficult for any user programs reading /proc/stat to trace
> the entry back
> to a physical device. Any program must make assumptions that
> major numbers 8
> and 22 refer to /dev/hd* entries, and that disk number 0
> translates to 'a',
> 1 to 'b', 2 to 'c', etc and can then work out that 22,2 means
> /dev/hdc.
> These assumption, of course, break with the use of devfs when
> not using
> devfsd to provide the necessary links.
>
> I welcome any comments, but please CC me directly as I'm not
> subscribed to
> the list.
>
> Tony...
> --
> Tony Young
> Senior Software Engineer
> Integrated Research Limited
> Level 10, 168 Walker St
> North Sydney, NSW 2060, Australia
> Ph: +61 2 9966 1066
> Fax: +61 2 9966 1042
> Mob: 0414 649942
>
> -
> 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/
>
next reply other threads:[~2001-03-26 0:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-26 0:14 Tony.Young [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-03-23 15:01 Dupuis, Don
2001-03-23 3:55 Tony.Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C0D2F5944500D411AD8A00104B31930E8D3CB7@ir_nt_server2 \
--to=tony.young@ir.com \
--cc=Don.Dupuis@COMPAQ.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®