From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 26 02:12:02 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org Delivered-To: FreeBSD-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C8AB16A41F for ; Mon, 26 Sep 2005 02:12:02 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7824443D48 for ; Mon, 26 Sep 2005 02:12:00 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (patr530-a042.otenet.gr [212.205.215.42]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j8Q2BfE6009077; Mon, 26 Sep 2005 05:11:42 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8Q2BABb002608; Mon, 26 Sep 2005 05:11:10 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8Q2B9wU002607; Mon, 26 Sep 2005 05:11:09 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Mon, 26 Sep 2005 05:11:09 +0300 From: Giorgos Keramidas To: Frank Mayhar Message-ID: <20050926021109.GA2576@flame.pc> References: <1127618793.38683.9.camel@realtime.exit.com> <20050925110005.GB819@flame.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050925110005.GB819@flame.pc> Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 02:12:02 -0000 On 2005-09-25 14:00, Giorgos Keramidas wrote: > On 2005-09-24 20:26, Frank Mayhar wrote: > > I've been using libufs as the I/O mechanism for my (heavy) modification > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > other bits and pieces to maybe get it suitable for release into the > > wild. I just looked at cgread() to see what it does and noticed that > > there seems to be a redundant line: > > > > . > > . > > if (c >= fs->fs_ncg) { > > return (0); > > } > > ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; > > if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, > > . > > . > > > > That assignment up there looks redundant, as ccg is never used. I > > suspect that it's a relic of an old lseek()/read() pair that's long > > gone. > > It's probably easy to verify that without this assignment 'ccg' is an > unused var: > > - Comment it out > - Rebuild with an elevated WARNS level > > if a warning about 'unused ccg var' is printed, then you are certain > that ccg was only used for the assignment. FWIW, libufs built with the following patch seems to pass at least a build test fine, even with WARNS=6 %%% Index: cgroup.c =================================================================== RCS file: /home/ncvs/src/lib/libufs/cgroup.c,v retrieving revision 1.3 diff -u -r1.3 cgroup.c --- cgroup.c 9 Jun 2003 09:32:29 -0000 1.3 +++ cgroup.c 26 Sep 2005 02:09:07 -0000 @@ -55,14 +55,12 @@ cgread1(struct uufsd *disk, int c) { struct fs *fs; - off_t ccg; fs = &disk->d_fs; if (c >= fs->fs_ncg) { return (0); } - ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, fs->fs_bsize) == -1) { ERROR(disk, "unable to read cylinder group"); %%%