From owner-freebsd-current  Sat Dec  6 14:10:33 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA18548
          for current-outgoing; Sat, 6 Dec 1997 14:10:33 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA18522;
          Sat, 6 Dec 1997 14:10:18 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id OAA03207;
	Sat, 6 Dec 1997 14:00:59 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd003203; Sat Dec  6 14:00:49 1997
Date: Sat, 6 Dec 1997 13:58:24 -0800 (PST)
From: Julian Elischer <julian@whistle.com>
To: Bruce Evans <bde@zeta.org.au>
cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: DEVFS: John, can you suggest..
In-Reply-To: <199712060511.QAA31383@godzilla.zeta.org.au>
Message-ID: <Pine.BSF.3.95.971206135341.19124A-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Thanks for the pointer.. I was certain it was something like that.  I'll
look into trying to fix this.  It really needs to be the result of an
ioctl on the device or some other "ask the device" operation.. 

I'll make this my "project of the day" (that and the laundry, now that
they have Mike Smith's Canadian Quarters out of the machine and it works
again)  :-)

julian

> ><my stuff>
> >spec_strategy
> >spec_vnoperate
> >spec_getpages
> >spec_vnoperate
> 
> spec_getpages() always rounds up to a multiple of a block size.  However,
> in the mounted case, this block size is vp->v_mount->mnt_stat.f_bsize.
> Apparently f_bsize is not a multiple of 512.
> 
> There are lots of related bogons.  E.g., the cluster_write() call in
> spec_strategy() flounders around using the f_bsize and other unrelated
> values for the filesystem that the device node happens to be in.
> Perhaps your problem is actually here.  There is no problem for ffs
> because spec_bmap() returns a run length of 0, so cluster_write()
> reduces to a slow way of calling bawrite() or bdwrite() (depending
> bogusly on whether the filesystem is mounted -async).
> 
> Bruce
>