Re: multiple issues with devstat_*(9)

From: Alexander Best <arundel_at_freebsd.org>
Date: Mon, 4 Apr 2011 20:43:16 +0000
On Fri Apr  1 11, John Baldwin wrote:
> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
> > hi there,
> > 
> > i think there are multiple issues with devstat. i found the following in
> > devicestat.h:
> > 
> > /*
> >  * These types are intended to aid statistics gathering/display programs.
> >  * The first 13 types (up to the 'target' flag) are identical numerically
> >  * to the SCSI device type numbers.  The next 3 types designate the device
> >  * interface.  Currently the choices are IDE, SCSI, and 'other'.  The last
> >  * flag specifies whether or not the given device is a passthrough device
> >  * or not.  If it is a passthrough device, the lower 4 bits specify which
> >  * type of physical device lies under the passthrough device, and the next
> >  * 4 bits specify the interface.
> >  */
> > typedef enum {
> >         DEVSTAT_TYPE_DIRECT     = 0x000,
> >         DEVSTAT_TYPE_SEQUENTIAL = 0x001,
> >         DEVSTAT_TYPE_PRINTER    = 0x002,
> >         DEVSTAT_TYPE_PROCESSOR  = 0x003,
> >         DEVSTAT_TYPE_WORM       = 0x004,
> >         DEVSTAT_TYPE_CDROM      = 0x005,
> >         DEVSTAT_TYPE_SCANNER    = 0x006,
> >         DEVSTAT_TYPE_OPTICAL    = 0x007,
> >         DEVSTAT_TYPE_CHANGER    = 0x008,
> >         DEVSTAT_TYPE_COMM       = 0x009,
> >         DEVSTAT_TYPE_ASC0       = 0x00a,
> >         DEVSTAT_TYPE_ASC1       = 0x00b,
> >         DEVSTAT_TYPE_STORARRAY  = 0x00c,
> >         DEVSTAT_TYPE_ENCLOSURE  = 0x00d,
> >         DEVSTAT_TYPE_FLOPPY     = 0x00e,
> >         DEVSTAT_TYPE_MASK       = 0x00f,
> >         DEVSTAT_TYPE_IF_SCSI    = 0x010,
> >         DEVSTAT_TYPE_IF_IDE     = 0x020,
> >         DEVSTAT_TYPE_IF_OTHER   = 0x030,
> >         DEVSTAT_TYPE_IF_MASK    = 0x0f0,
> >         DEVSTAT_TYPE_PASS       = 0x100
> > } devstat_type_flags;
> > 
> > 
> > also the devstat(9) man page says:
> > 
> >      Each device is given a device type.  Pass-through devices have the same
> >      underlying device type and interface as the device they provide an inter-
> >      face for, but they also have the pass-through flag set.  The base device
> >      types are identical to the SCSI device type numbers, so with SCSI periph-
> >      erals, the device type returned from an inquiry is usually ORed with the
> >      SCSI interface type and the pass-through flag if appropriate.  The device
> >      type flags are as follows:
> > 
> > ...so let's get started:
> > 
> > otaku% iostat -n100
> >        tty            ada0             ada1              md0              cd0            pass0            pass1            pass2             cpu
> >  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> >    1    92 21.18   0  0.01  24.37  12  0.29   0.00   0  0.00  60.27   0  0.01   0.37   0  0.00   0.37   0  0.00   0.00   0  0.00   5  0  4  0 90
> > 
> > ..so far so good
> > 
> > otaku% iostat -t da
> >        tty            ada0             ada1              md0             cpu
> >  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> >    1    92 21.18   0  0.01  24.37  12  0.29   0.00   0  0.00   5  0  4  0 90
> > 
> > ...not good! this should include two pass devices!
> 
> This is probably due to the hard drives being IDE (really ATA) rather than
> SCSI.  I agree this should show the pass devices.

hmmmm...one could argue. the drives are ATA, however they are being associated
to the CAM subsystem. depends what one considers under "scsi interface".
personally i'd like to see them inder "scsi".

> 
> > otaku% iostat -t scsi
> >        tty             cd0             cpu
> >  tin  tout  KB/t tps  MB/s  us ni sy in id
> >    1    92 60.27   0  0.01   5  0  4  0 90
> > 
> > ..what?
> 
> If cd0 is an ATAPI CD-ROM drive, then this shouldn't even show cd0 as all of
> your devices are IDE/ATA, not SCSI.
> 
> > otaku% iostat -t ide
> >        tty            cpu
> >  tin  tout us ni sy in id
> >    1    92  5  0  4  0 90
> > otaku% iostat -t other
> >        tty            cpu
> >  tin  tout us ni sy in id
> >    1    92  5  0  4  0 90
> > 
> > ...what about md0? ada0? ada1? md0?
> 
> md0 is a memory disk, it is neither SCSI nor IDE.  However, -t ide (or even
> better, a -t ata), should show all of your other devices (adaX and cd0) along
> with their passX devices I think.

so md0 should show up under -t other. i don't think there's a -t ata.

> 
> > otaku% iostat -t cd0
> >        tty             cd0             cpu
> >  tin  tout  KB/t tps  MB/s  us ni sy in id
> >    1    92 60.27   0  0.01   5  0  4  0 90
> > 
> > ...this should also include a pass device
> 
> Agreed.
> 
> > 
> > otaku% iostat -t pass
> >        tty           pass0            pass1            pass2             cpu
> >  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> >    1    92  0.37   0  0.00   0.37   0  0.00   0.00   0  0.00   5  0  4  0 90
> > 
> > ...this one's working as expected.
> > 
> > funny thing is i found the following in scsi_pass.c:
> > 
> >         softc->device_stats = devstat_new_entry("pass",
> >                           periph->unit_number, 0,
> >                           DEVSTAT_NO_BLOCKSIZE
> >                           | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0),
> >                           softc->pd_type |
> >                           DEVSTAT_TYPE_IF_SCSI |
> >                           DEVSTAT_TYPE_PASS,
> >                           DEVSTAT_PRIORITY_PASS);
> > 
> > ...so pass* *should* show up under iostat -t scsi.
> 
> Hmm, pass devices for adaX should not be SCSI though, they should be ide I
> think.

i think the situation with ATA_CAM should be discussed further. still besides
this issue there are many more with devstat(3).


i'll try to track all the "devstat_new_entry()" occurrences and see if some
issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten.

> 
> -- 
> John Baldwin

-- 
a13x
Received on Mon Apr 04 2011 - 18:43:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC