From owner-freebsd-hackers  Thu Dec 13 19: 4:27 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0075037B41B; Thu, 13 Dec 2001 19:04:24 -0800 (PST)
Received: from pool0149.cvx22-bradley.dialup.earthlink.net ([209.179.198.149] helo=mindspring.com)
	by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 16Eidy-0004Vy-00; Thu, 13 Dec 2001 19:04:14 -0800
Message-ID: <3C196C33.2A3A6BD0@mindspring.com>
Date: Thu, 13 Dec 2001 19:04:19 -0800
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: David Greenman <dg@root.com>,
	Jordan Hubbard <jkh@winston.freebsd.org>,
	Peter Wemm <peter@wemm.org>, Mike Smith <msmith@FreeBSD.ORG>,
	hackers@FreeBSD.ORG, msmith@mass.dis.org
Subject: Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data 
 corruption bug... (was Re:...))
References: <58885.1008217148@winston.freebsd.org> <200112130608.fBD689K49906@apollo.backplane.com> <20011212224927.A73226@nexus.root.com> <200112131835.fBDIZuL70031@apollo.backplane.com> <3C18FAC9.E743DAA5@mindspring.com> <200112140042.fBE0gBa61696@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

Matthew Dillon wrote:
>     Hmm.  Well, my code is definitely broken.  My 'adj' calculation is
>     all wrong.  However, my size calculation appears to be correct.
>     (size - adj) is the size of the block after the base has been adjusted
>     to the next full chunk.  The number of chunks we then generate bits
>     for must be fully enclosed by size and (new_size & ~(DEV_BSIZE - 1))
>     gives that to us.  e.g. if new_size is less then DEV_BSIZE we get 0,
>     correctly indicating that we cannot clear any dirty bits at all.

I missed the size of the operand to the twiddle; mea culpa.  I
thought you were (effectively) getting a "mod" operation on a
"div"'ed value, not the total value.

Never mind.  8^).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message