mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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/
> 

             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®