From owner-freebsd-current  Fri Dec  5 21:29:50 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA19261
          for current-outgoing; Fri, 5 Dec 1997 21:29:50 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18871;
          Fri, 5 Dec 1997 21:22:10 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id QAA31383; Sat, 6 Dec 1997 16:11:09 +1100
Date: Sat, 6 Dec 1997 16:11:09 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712060511.QAA31383@godzilla.zeta.org.au>
To: dyson@FreeBSD.ORG, julian@whistle.com
Subject: Re: DEVFS: John, can you suggest..
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>My new DEVFS/SLICE code seems to work fine..
>except:
>occasionally I get a call from the system to transfer an 
>amount of data that is not a multiple of 512 bytes.
>
>actually 4736 bytes to be exact.
>( (9 * 512) + 128 )
>...
>The stack trace is:
>(by hand)
>
><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