From owner-freebsd-bugs@FreeBSD.ORG Wed Jan 4 02:10:08 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DD5E16A455 for ; Wed, 4 Jan 2006 02:10:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D4F743D48 for ; Wed, 4 Jan 2006 02:10:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k042A7OQ075076 for ; Wed, 4 Jan 2006 02:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k042A7hD075075; Wed, 4 Jan 2006 02:10:07 GMT (envelope-from gnats) Date: Wed, 4 Jan 2006 02:10:07 GMT Message-Id: <200601040210.k042A7hD075075@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: bin/91034: minor fix to iostat so that columns line up with 128KB xfers X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 02:10:08 -0000 The following reply was made to PR bin/91034; it has been noted by GNATS. From: Bruce Evans To: Giorgos Keramidas Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: bin/91034: minor fix to iostat so that columns line up with 128KB xfers Date: Wed, 4 Jan 2006 13:09:02 +1100 (EST) On Tue, 3 Jan 2006, Giorgos Keramidas wrote: > On 2006-01-03 22:40, Bruce Evans wrote: >> On Tue, 3 Jan 2006, Giorgos Keramidas wrote: >>> On 2005-12-28 21:16, Robert Cousins wrote: >>>> Iostat's output can be kind of ugly under USF2 with 128KB >>>> transfers. Here is an example: >>>> ... >>>> The patch I'm submitting notices when this value is >= 100 and >>>> drops from 2 decimals to 1 in this case. The result is an output >>>> like this: >>> ... >>> The misaligned dots seem a bit ugly. >> ... >>> Is it ok to use %6.2Lf as >>> the format specifier, widening the KB columns a bit to fit the >>> new length of the text? >> >> No. There is space in the above, but most systems have more than 2 drives >> ... > > So, there's no way to keep the pretty format of current iostat output > *and* account for larger transfer speeds? :-( Maybe always drop %5.1Lf format for disk MB/s. If the value is < 0.10 MB/s then it is so low that you don't really care if it is 0.01 or 0.09. However, floppies have a top speed of about 0.04, and speeds below 0.10 are all too common for faster disks doing too many seeks. > Looking at an awk-formatted version of the iostat output it seems that > even with 3 disks we *do* hae 3 columns to spare until 79 columns are > reached: > > $ iostat ad0 da0 pass0 | awk '{printf "%-78s|\n",$0}' > tty ad0 da0 pass0 cpu | > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id | > 63 514 7.10 13 0.09 0.01 0 0.00 0.00 0 0.00 1 0 2 0 96 | > $ > > Is this enough for adding an extra column to every KB/t column and > still keeping everything under 80 columns? No, since there are actually only 2 columns to spare. "id" sometimes takes an extra column since it is sometimes 100. I hacked its format in rev.1.25 of iostat.c from %3.0f to " %2.0f". The space keeps it from running into "in", and reducing the field width keeps the line length the same except when cpu is 100 when it doesn't fit in %2.0f. As mentioned in the log message for this, larger fixes are needed. I think they should be something like "iostat -w N | awk '{printf "%*.*s %*.*s ...\n", $1, $2, ...}'" where the awk script calculates the column widths dynamically and is actually a library function. This should also work for ps and df. It's easier for them since all the input can be read before doing any output. Except I'd like ps to have a "repeat" arg like iostat, for watching a few selected processes better than top(1) or repeatedly rerunning ps(1) can do. Bruce