Re: possible bug in ll_rw_blk.c in 2.0.x and 2.1.x

Chris Dent (cdent@kiva.net)
Sun, 16 Nov 1997 11:04:33 -0500 (EST)


On Sun, 16 Nov 1997, Torbjorn Lindgren wrote:

> On Sat, 15 Nov 1997, Chris Dent wrote:
> > I think I may have found a possible bug (or a misfeature caused by
> > some bad planning) in driver/block/ll_rw_blk.c in add_request. It is
> > also possible that I'm misunderstanding the code. I'm doing most of my
> > poking in 2.0.30pre(9|10) but the code looks the same in 2.1.64.
>
> IMNSHO most of the disk statistics code in Linux 2.0 is "bad". The main
> misfeatures of it is:
>
> 1) Puts statistics for different majors in the same field.
> 2) Has a hard-coded number of disk-"fields"
>
> While it's relatively easy to change it to a different hard-coded number,
> that doesn't fix the basic problems with the code.

I completely agree. I addressed the issue from that standpoint because
going for the 'real' fix was even more daunting.

> I think the best would be to define a good output format and implement
> it, and then use the stats to output "degraded" data into proc/stats
> (folding together IDE and SCSI, and just the first four disks).

What do you mean by 'folding together IDE and SCSI'?

> Depending on how most programs parses <proc>/stat it might be best to
> put this in a different proc-file.
>
> Unless someone else plans to do this I might take a stab at it later
> sometime. (Probably using an output format something like this:
> "disk-id <stats for disk-id>", repeated for all disks).

I think something which fundamental changes the <proc>/stat setup is
in order where stat becomes a directory and perhaps in there is
something like:

stat/disk/sd/{a,b,c,...}
stat/disk/hd/{a,b,c,...}

or just

stat/sd/{a,b,c...}
stat/hd/{a,b,c...}

Either of those would make it relatively easy for iostat like programs
to dynamically pick and choose amongst devices.

This would, of course, break a lot of stuff that reads proc but that
has been an ongoing trend over the past few years.

> > If someone does patch something into the kernel for this I would also
> > suggest including something along the line of what Terje Malmedal
> > supported in a message with subject: disk reporting in /proc/stat on
> > Oct 7, 1997. It allows greater than 4 disks to be reported.
>
> It replaces one hard-limit with another hard-limit, admittedly a
> changable hard-limit, without addressing the other concerns. It's
> better than nothing, but could also break existing programs (if they
> expect exactly four numbers), if they are badly written.

I think breaking programs is going to be inevitable if the goal is to
get better (more correct) disk statistics.

..........................
Chris Dent........SysAdmin
...........Kiva Networking