--LyciRD1jyfeSSjG0
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
>=20
> On Tue, Sep 27, 2005 at 08:42:15AM -0700, Jason Thorpe wrote:
> > No objections here -- I'm all for simplifying the VFS layer.
>=20
> That brings me to the following question regarding DEV_BSIZE (see=20
> discusstion earlier on tech-kern):
>=20
> Is the wedge system to provide a new interface for filingsystems to disc=
=20
> 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=
=20
> interface to discs to replace it with a *sector-size* oriented interface =
so=20
> various filingsystems like msdosfs and udf eventually can support non 512=
=20
> bytes/sector filingsystems?

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

> There has been several patches around for yonks that fixes these issues b=
ut=20
> they were never integrated. Our msdosfs f.e. doesn't support non 512=20
> bytes/sector devices. Filingsystems DO change on sectorsize and devices=
=20
> like DVD/CD+-(M)R(W) can't just do read-modify-write cycle to cope with=
=20
> 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=
=20
bread() and bwrite() are counted.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDSotHWz+3JHUci9cRAluQAJ415gmFdvYMIHIIRHNdc9I984cowgCfVPn3
/W86OUa+6HOE/lrSMz0FKXQ=
=xjrQ
-----END PGP SIGNATURE-----

--LyciRD1jyfeSSjG0--