--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 10, 2005 at 09:21:25PM +0200, Reinoud Zandijk wrote:
> On Mon, Oct 10, 2005 at 08:39:51AM -0700, Bill Studenmund wrote:
> > On Sat, Oct 08, 2005 at 02:37:21PM +0200, Reinoud Zandijk wrote:
> > I doubt it. I also don't think it'd be preferable. Changing disklabelin=
g=20
> > will be a big-enough issue, let's not complicate things.
>=20
> it wouldn't mean changing if the disk is 512 bytes/sector ;)

Yes, it would. It would mean fixing everything to work with=20
non-512-byte/sector disks. The fact that it all washes out in the end for=
=20
512-byte disks does not mean we don't have to do the work. If anything, it=
=20
makes it harder as we have to have non-512-byte disks to test everything.

> > I think you should look at how things work now. DEV_BSIZE is not limiti=
ng=20
> > how file systems work.
>=20
> it does! The filing system now to has to make sure it is allways=20
> sending/requesting a multiple of 512 for the sector size bringing the=20
> burdon to the filingsystem.

And exactly what burden is this? And what point do you want to make?

You're saying you want to support using the device's sector size. But the=
=20
sector size is greater than DEV_BSIZE. So how is making things a multiple=
=20
of DEV_BSIZE going to hurt? The device's sector size is an integer=20
multiple of it (and unless things are insane, it is a power-of-two=20
multiple). So we have a much larger restriction, the device's sector size,=
=20
in place.

> > 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.
>=20
> scsipi's cd.c does :-S

Yes & no. AFAICT all of that code deals with the case where the disklabel
size is not equal to the device's real size. However the disklabel's
sector size is the device's sector size to the rest of the kernel. So=20
regardless of DEV_BSIZE or not, we would have that layer due to the fact=20
the device was lying to the rest of the kernel.

> > At this point in time, DEV_BSIZE is just a unit in which block numbers =
for=20
> > bread() and bwrite() are counted.
>=20
> and this is part of the evil... for calculations have to be made=20
> translating them to sector numbers and back.

When do you have to translate back?

For efficiency, _every_ file system is going to do i/o in multiples of the=
=20
sector size. So you will always have the translation between fs blocks and=
=20
disk blocks, and fs blocks will be larger than disk blocks. So you're=20
going to do the same work either way.

Take care,

Bill

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

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

iD8DBQFDS+6ZWz+3JHUci9cRAq+vAJ9PRYEyeykfgde7eCGaBa68UNxWQgCgk7Iw
zqUbOtb5ZsfUwM7Fo9V3UPY=
=qdk8
-----END PGP SIGNATURE-----

--OgqxwSJOaUobr8KG--