Re: multiple issues with devstat_*(9)
On Mon Apr 11 11, Kenneth D. Merry wrote: On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch i just tried again with ATA_CAM and the patch works perfectly. iostat -t scsi doesn't show any devices and iostat -t ide shows all my ata/sata devices in addition to pass* under iostat -t pass and md* under iostat -t other. +1 for committing it. :) cheers. alex Any objections? Or SCSI/IDE there expected to mean command set? For what it's worth, I think the above patch is the right approach. The device type stuff in devstat has been broken since GEOM went in, so I'm glad to see you step up to fix it! Ken -- Kenneth Merry k...@freebsd.org -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
Alexander Best wrote: On Sun Apr 10 11, Alexander Motin wrote: Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0 pass0pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: On Sun Apr 10 11, Alexander Motin wrote: Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0 pass0pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. thanks for the hint. i also read the following in the ahci(4) man page: Driver features include support for Serial ATA and ATAPI devices, ... ...does that mean that my DVD drive can also attach to the ahci driver? cheers. alex -- Alexander Motin -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
Alexander Best wrote: On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. thanks for the hint. i also read the following in the ahci(4) man page: Driver features include support for Serial ATA and ATAPI devices, ... ...does that mean that my DVD drive can also attach to the ahci driver? If it is SATA and you connect it to AHCI controller -- yes, it will work with ahci(4) controller driver. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. thanks for the hint. i also read the following in the ahci(4) man page: Driver features include support for Serial ATA and ATAPI devices, ... ...does that mean that my DVD drive can also attach to the ahci driver? If it is SATA and you connect it to AHCI controller -- yes, it will work with ahci(4) controller driver. no it's PATA. thanks for the help. i'll remove atapicam from my kernel conf and add ATA_CAM. maybe we could have a list of supported controllers in the ahci(4) man page. will the ataahci driver also dissapear soon? cheers. alex -- Alexander Motin -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On 11.04.2011 12:34, Alexander Best wrote: On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: On Mon Apr 11 11, Alexander Motin wrote: Alexander Best wrote: my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device pass device da device random device pty device md the dmesg entries for cd0 are: cam_periph_alloc: attempt to re-allocate valid device cd0 rejected cdasync: Unable to attach new device due to status 0x6 cd0 at ata2 bus 0 scbus8 target 0 lun 0 cd0:HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. thanks for the hint. i also read the following in the ahci(4) man page: Driver features include support for Serial ATA and ATAPI devices, ... ...does that mean that my DVD drive can also attach to the ahci driver? If it is SATA and you connect it to AHCI controller -- yes, it will work with ahci(4) controller driver. no it's PATA. thanks for the help. i'll remove atapicam from my kernel conf and add ATA_CAM. maybe we could have a list of supported controllers in the ahci(4) man page. We could do it (you can find list of known inside ahci.c), but unlike others, AHCI is an open specification, so that list will never be complete. Also on some chipsets AHCI support also depends on BIOS, so specification of just a chipset revisions can be inaccurate. will the ataahci driver also dissapear soon? Yes, at least disabled. Same as most part of the atasiliconimage and the atamarvell. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch Any objections? Or SCSI/IDE there expected to mean command set? For what it's worth, I think the above patch is the right approach. The device type stuff in devstat has been broken since GEOM went in, so I'm glad to see you step up to fix it! Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0 pass0pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. As I have told - it is a bug/feature of libdevstat. It should not be difficult to fix, if it is really a bug.
Re: multiple issues with devstat_*(9)
On 11.04.2011 18:43, Kenneth D. Merry wrote: On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: Alexander Best wrote: 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. As I have told - it is a bug/feature of libdevstat. It should not be difficult to fix, if it is really a bug. That was intentional, if I can remember what I intended in 1997/1998. The reason was that since there is one passthrough device created for every device that CAM manages, you don't want to show pass(4) devices when the user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, depending on the order of devices in the system. But, if it's pass(4) devices you want, you can ask for them specifically, or for all SCSI/IDE pass(4) devices, as mav did above. But it is impossible to get, for example, all SCSI devices including pass. Either only non-pass, or pass only. It is strange that if I won't specify -t (most probable for inexperienced users), I'll gel all devices including pass, but if specify -t scsi (as more advanced user who knows what to ask), I'll get only non-pass. It is at least inconsistent. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Mon, Apr 11, 2011 at 19:09:00 +0300, Alexander Motin wrote: On 11.04.2011 18:43, Kenneth D. Merry wrote: On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: Alexander Best wrote: 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. As I have told - it is a bug/feature of libdevstat. It should not be difficult to fix, if it is really a bug. That was intentional, if I can remember what I intended in 1997/1998. The reason was that since there is one passthrough device created for every device that CAM manages, you don't want to show pass(4) devices when the user says 'iostat -t scsi'. Otherwise he might get all pass(4) devices, depending on the order of devices in the system. But, if it's pass(4) devices you want, you can ask for them specifically, or for all SCSI/IDE pass(4) devices, as mav did above. But it is impossible to get, for example, all SCSI devices including pass. Either only non-pass, or pass only. It is strange that if I won't specify -t (most probable for inexperienced users), I'll gel all devices including pass, but if specify -t scsi (as more advanced user who knows what to ask), I'll get only non-pass. It is at least inconsistent. Perhaps it is somewhat inconsistent, and we should do some filtering by default to not show pass(4) devices. The idea was that in most cases, people will not want to see the pass(4) devices. That is not where most of the I/O typically happens. If they want to see the pass(4) devices, they can ask for them specifically by type or by name. When I have a system full of drives and I want to look at one particular pass(4) device, I always specify it manually, e.g.: 'iostat -d pass4 1' Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Mon Apr 11 11, Kenneth D. Merry wrote: On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote: Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0 pass0pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then
Re: multiple issues with devstat_*(9)
On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0pass0 pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. 3) md0 should show up under iostat -t other cheers. alex Any objections? Or SCSI/IDE there expected to mean command set? -- Alexander Motin -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
On Sun Apr 10 11, Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0pass0 pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. 3) md0 should show up under iostat -t other sorry this was my fault. there was no md* configured at the time i ran the test. md0 showx up under iostat -t da and iostat -t other, just like it's supposd to. so please forget about point 3). cheers. alex cheers. alex Any objections? Or SCSI/IDE there expected to mean command set? -- Alexander Motin -- a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0pass0 pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). 2) the pass* devices still don't show up under ide/scsi/other. that's ok, but then the src comments and manual pages need to be changed accordingly. As I have told - it is a bug/feature of libdevstat. It should not be difficult to fix, if it is really a bug. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send
Re: multiple issues with devstat_*(9)
On Sun Apr 10 11, Alexander Motin wrote: Alexander Best wrote: On Thu Apr 7 11, Alexander Motin wrote: Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch with your patch i get the following output: otaku% iostat -t ide ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 otaku% iostat -t scsi tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 6 146 2.32 0 0.00 2 0 3 0 95 otaku% iostat -t pass tty pass0pass1pass2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 otaku% iostat -t da ttyada0 ada1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 otaku% iostat -t cd tty cd0 cpu tin tout KB/t tps MB/s us ni sy in id 7 147 2.32 0 0.00 1 0 3 0 95 otaku% iostat -t other ttycpu tin tout us ni sy in id 7 149 1 0 3 0 95 otaku% iostat -n 100 ttyada0 ada1 cd0 pass0pass1pass2 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 us ni sy in id 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 the the remaining issues imho are: 1) ada* and cd* are SATA/ATA devices. so i think they should show up together either under ide *or* scsi. i don't have any *real* scsi devices. I've just retested the patch and haven't reproduced your problem: %iostat -d da0 ada0 da1 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 %iostat -d -t ide da0 ada0 cd0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 %iostat -d -t scsi da1 KB/t tps MB/s 2.65 1 0.00 %iostat -d -t pass pass0pass1pass2pass3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t ide,pass pass0pass1pass2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 %iostat -d -t scsi,pass pass3 KB/t tps MB/s 0.00 0 0.00 da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA ATAPI CD-ROM. Just an idea, aren't you are using legacy ata(4) + atapicam for your cd0? atapicam lies that it's buses are SPI (SCSI). my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: device atacore device ahci device atajmicron device atapci #device atapicd device atapicam device umass device scbus device cd device
Re: multiple issues with devstat_*(9)
on 08/04/2011 08:51 Andriy Gapon said the following: on 07/04/2011 13:59 Alexander Motin said the following: Any objections? Or SCSI/IDE there expected to mean command set? Sorry for saying something potentially stupid, but... do we actually have any reason to make that distinction from any practical point? And the following could be related here too: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/81497 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: i think there are multiple issues with devstat. i found the following in devicestat.h: ... 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. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request pass specifically. 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. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch Any objections? Or SCSI/IDE there expected to mean command set? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
on 07/04/2011 13:59 Alexander Motin said the following: Any objections? Or SCSI/IDE there expected to mean command set? Sorry for saying something potentially stupid, but... do we actually have any reason to make that distinction from any practical point? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
John Baldwin wrote: On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: This is probably due to the hard drives being IDE (really ATA) rather than SCSI. I agree this should show the pass devices. h...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. No, SCSI is a transport protocol. Alexandar Motin's work added a new transport layer that speaks ATA and that is what ada uses. CAM does not send SCSI commands to adaX devices AFAIK. Generally right, but to be complete: CAM differentiates types at transport and protocol layers. At the protocol layer there are SCSI and ATA protocols (used by da and ada drivers respectively, for example). At the transport layer there never was such thing as SCSI, there are: SPI, FC, SAS, PPB, USB (several protocols), iSCSI, etc. All of them can handle SCSI commands. Newly added ATA and SATA transports handle both ATA and SCSI commands: ATA -- always, SCSI -- optionally, using ATAPI extension. otaku% iostat -t ide ttycpu tin tout us ni sy in id 192 5 0 4 0 90 otaku% iostat -t other ttycpu tin tout us ni sy in id 192 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. Yes, I think we should possibly add a -t ata, possibly as an alias for -t ide. Have no objections, but I would like to clarify what exactly that option should mean. It is simple for cases of SATA and SAS disks -- first is IDE/ATA (ATA/SATA), second is SCSI (SCSI/SAS). But it becomes tricky for ATA/SATA CD/DVD, ZIP/MO, tape drives - they use SCSI protocol commands, but ATA/SATA transport. As result, while adaX devices are definitely IDE (ATA) from any point of view; cdX, daX, saX, etc. can use any transport. So should they be reported as SCSI, respecting command protocol, or IDE (ATA), respecting transport? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
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
ttyada0 ada1 md0
cd0pass0pass1pass2 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
192 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
ttyada0 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
192 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.
h...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
192 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
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
otaku% iostat -t other
ttycpu
tin tout us ni sy in id
192 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
192 60.27 0 0.01 5 0 4 0 90
...this should also include a pass device
Agreed.
otaku% iostat -t pass
tty pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 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,
Re: multiple issues with devstat_*(9)
On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: This is probably due to the hard drives being IDE (really ATA) rather than SCSI. I agree this should show the pass devices. h...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. No, SCSI is a transport protocol. Alexandar Motin's work added a new transport layer that speaks ATA and that is what ada uses. CAM does not send SCSI commands to adaX devices AFAIK. otaku% iostat -t ide ttycpu tin tout us ni sy in id 192 5 0 4 0 90 otaku% iostat -t other ttycpu tin tout us ni sy in id 192 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. Yes, I think we should possibly add a -t ata, possibly as an alias for -t ide. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multiple issues with devstat_*(9)
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
ttyada0 ada1 md0 cd0
pass0pass1pass2 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
192 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
ttyada0 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
192 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.
otaku% iostat -t scsi
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 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
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
otaku% iostat -t other
ttycpu
tin tout us ni sy in id
192 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.
otaku% iostat -t cd0
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
...this should also include a pass device
Agreed.
otaku% iostat -t pass
tty pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 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.
--
multiple issues with devstat_*(9)
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
ttyada0 ada1 md0 cd0
pass0pass1pass2 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
192 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
ttyada0 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
192 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!
otaku% iostat -t scsi
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
..what?
otaku% iostat -t ide
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
otaku% iostat -t other
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
...what about md0? ada0? ada1? md0?
otaku% iostat -t cd0
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
...this should also include a pass device
otaku% iostat -t pass
tty pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 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.
this is all very weird. it seems the DEVSTAT_TYPE_IF_* stuff has some major
problems. also the pass* devices aren't beeing aasigned to DEVSTAT_TYPE_DIRECT
and DEVSTAT_TYPE_CDROM, as devstat(9) suggests.
cheers.
alex
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
