Subject: Re: wedges and DEV_BSIZE (Was Re: removing VOPs)
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/10/2005 08:39:51
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 08, 2005 at 02:37:21PM +0200, Reinoud Zandijk wrote:
> Hiya Jason, hiya Folks
> On Tue, Sep 27, 2005 at 08:42:15AM -0700, Jason Thorpe wrote:
> > No objections here -- I'm all for simplifying the VFS layer.
> That brings me to the following question regarding DEV_BSIZE (see=20
> discusstion earlier on tech-kern):
> Is the wedge system to provide a new interface for filingsystems to disc=
> devices or wouldn't that be preferable?

I doubt it. I also don't think it'd be preferable. Changing disklabeling=20
will be a big-enough issue, let's not complicate things.

> Wouldn't it then be the time to also scrap the fixed DEV_BSIZE blocksize=
> interface to discs to replace it with a *sector-size* oriented interface =
> various filingsystems like msdosfs and udf eventually can support non 512=
> bytes/sector filingsystems?

I think you should look at how things work now. DEV_BSIZE is not limiting=
how file systems work.

> There has been several patches around for yonks that fixes these issues b=
> they were never integrated. Our msdosfs f.e. doesn't support non 512=20
> bytes/sector devices. Filingsystems DO change on sectorsize and devices=
> like DVD/CD+-(M)R(W) can't just do read-modify-write cycle to cope with=
> blocksizes smaller than the sector size.

Our device drivers don't support read-modify-write operations now; all=20
reads and writes have to be a multiple of the underlying sector size.

At this point in time, DEV_BSIZE is just a unit in which block numbers for=
bread() and bwrite() are counted.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)