From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 5 18:52:16 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A8D916A41F; Mon, 5 Sep 2005 18:52:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB39243D48; Mon, 5 Sep 2005 18:52:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j85IqClm017944; Mon, 5 Sep 2005 12:52:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <431C93DD.20402@samsco.org> Date: Mon, 05 Sep 2005 12:52:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rajesh S. Ghanekar" References: <17db6d3a0509051000622868bc@mail.gmail.com> <431C8D5B.7080309@samsco.org> <431C92F2.9090104@persistent.co.in> In-Reply-To: <431C92F2.9090104@persistent.co.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Adding new option to ktrace X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 18:52:16 -0000 Rajesh S. Ghanekar wrote: > Scott Long wrote: > >> Nikhil Dharashivkar wrote: >> >>> Hi, >>> i want to hack the ktrace system call. Basically, I want to monitor >>> scsi disk IO through dastrategy() routine. >>> It seems that kern_ktrace.c implements different functions for >>> ktrace options like -tc / -ti ... etc (see man page). So, is it >>> possible to add new option for disk IO with new structure object >>> containing disk io information which will be pass to >>> ktr_submittrequest thr' ktr_request structure. >>> Will data will be written correctly in ktrace.out and will >>> kdump analyze that ? >>> >>> >>> >> >> What are you trying to monitor? Would the existing devstat interface >> work? > > > May be he requires how many bytes transferred (read/write) while a > process is executing. > I guess devstat doesn't do it from process context, it gives total IO > read/writes from a device, > if registred via devstat. Please correct me if I am wrong. > > > - Rajesh > There isn't a 1:1 correlation between the bytes that the userland program writes, and the bytes that actually get written to disk. Filesystem metadata writes will happen if the file needs to be extended, not to mention the access time being updated. Some writes won't even originate from a userland program, like swap writes. GEOM also decouples the I/O path, so it's not the user process that will actually do the write, it's the g_down kthread. I would think that this would make tracking I/O via ktrace very hard. Scott