From owner-freebsd-current  Tue May 13 07:38:32 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA22700
          for current-outgoing; Tue, 13 May 1997 07:38:32 -0700 (PDT)
Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA22694
          for <freebsd-current@freebsd.org>; Tue, 13 May 1997 07:38:26 -0700 (PDT)
Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2])
	by nlsystems.com (8.8.5/8.8.5) with SMTP id PAA00469;
	Tue, 13 May 1997 15:37:32 +0100 (BST)
Date: Tue, 13 May 1997 15:37:32 +0100 (BST)
From: Doug Rabson <dfr@nlsystems.com>
To: Joerg Wunsch <joerg_wunsch@interface-business.de>
cc: FreeBSD-current users <freebsd-current@freebsd.org>,
        jmz@cabri.obs-besancon.fr
Subject: Re: Big problem with b_blkno
In-Reply-To: <19970513135901.QU53254@ida.interface-business.de>
Message-ID: <Pine.BSF.3.95q.970513153548.464A-100000@herring.nlsystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Tue, 13 May 1997, J Wunsch wrote:

> Extract from physio():
> 
>                         bp->b_blkno = btodb(uio->uio_offset);
> 
> This block number is being passed down to the strategy routine of the
> block device drivers.  No uio_offset itself is being passed down
> whatsoever.  This is nonsense.
> 
> The only acceptable definition of btodb() could be
> 
> #define btodb(x) (x)
> 
> The actual definition is in /sys/i386/include/param.h, and looks much
> more complicated.  In particular, it employs a shift operation, and
> thus loses potential information from uio_offset, in the (wrong)
> assumption that all device drivers operate in DEV_BSIZE units.  While
> there's no actual loss of information for device drivers that operate
> with (2^n) * DEV_BSIZE {n >= 0} as their physical block size, this
> loss of information is fatal when it comes to `odd' physical block
> sizes, e.g. with CD-ROMs.  CD-ROMs can take a number of different
> block sizes, depending on the data format.  The two most popular block
> sizes are 2048 (CD-ROM, not much of a problem), and 2352 (CD-DA, CD
> `raw' blocks, big problem).
> 
> How to solve this problem?  Define btodb() as shown above, and fix up
> all block device drivers?  This looks like the cleanest way to me.
> Are there any other enlightening solutions?
> 
> (Jean-Marc, this means the bogus division in wormstart() needs to stay
> until the above problem is fixed.  Sigh.)

I don't know about any solutions but I think changing btodb would break
NFS since it plays silly games with the block numbers to support caching
of NFS files.

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 951 1891