From owner-cvs-sys  Wed May  6 00:17:09 1998
Return-Path: <owner-cvs-sys>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA27556
          for cvs-sys-outgoing; Wed, 6 May 1998 00:17:09 -0700 (PDT)
          (envelope-from owner-cvs-sys)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27533;
          Wed, 6 May 1998 00:16:34 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id RAA00161;
	Wed, 6 May 1998 17:10:21 +1000
Date: Wed, 6 May 1998 17:10:21 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199805060710.RAA00161@godzilla.zeta.org.au>
To: julian@whistle.com, phk@critter.freebsd.dk
Subject: Re: cvs commit: src/sys/kern vfs_cluster.c
Cc: bde@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG,
        cvs-sys@FreeBSD.ORG
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>It should really be a mount-option, shouldn't it ?

Sort of.  Mostly not.  Clustering is already a mount option, following
a suggestion a few months ago by someone named phk.  However, vn needs
an anti-clustering flag to prevent multiple layers of clustering, and
all devices need to to specify their minimum, best and maximum block
sizes better.

>>Talking of clusterring..
>>
>>One problem with clustering is the fact that the flag that dissallows
>>CLUSTERING is stored in the BDEVSW entry. 
>>
>>from sys/conf.h:
>>#define D_NOCLUSTERR 0x10000 /* disables cluter read */
>>#define D_NOCLUSTERW 0x20000 /* disables cluster write */
>>#define D_NOCLUSTERRW (D_NOCLUSTERR | D_NOCLUSTERW) 
>>
>> which is patently the wrong place for it. for several reasons: 
>>
>>1/ different SCSI devices may have different ideas about clustering..

Only vn needs it here, so this isn't a problem.  d_maxio is a problem.

>>2/ in DEVFS/SLICE, all disks come in through the same major number/devfs[]
>>entry no matter which driver they eventually get passed to.

DEVFS/SLICE could easily have bugs like that :-).

>>3/ [bc]devsw entries will totally go away anyhow.

Maybe.

Bruce