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:[EMAIL PROTECTED]]
> Sent: Saturday, 24 March 2001 02:02
> To: Tony Young; [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 9:55 PM
> To: [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
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/
