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

On Thu, Dec 29, 2005 at 12:36:47AM +0100, Reinoud Zandijk wrote:
> On Wed, Dec 28, 2005 at 01:33:34PM -0800, Bill Studenmund wrote:
> > On Sat, Dec 24, 2005 at 02:41:54PM +0100, Reinoud Zandijk wrote:

[snip]

> true. Well part of my venturing out was to get new ways of solving the=20
> problems without resorting to the `we normally do it this way' solutions.=
=20
> Solutions where LFS might gain from too yes.=20
>=20
> I'll try out the reassign though i wonder what problems and complexity=20
> might arise from mismatched vop_strategy() buffer sizes and disc logicl=
=20
> block sizes. vop_strategy() now requests buffers upto say 64 kb/piece and=
=20
> the logical block size might be 2kb. Each part of 2kb can/could be stored=
=20
> somewhere else on disc. Normally a VOP_BMAP could determine the extent it=
=20
> could take in one go but looking up such information can be costly.

vop_strategy() makes requests sized as the file system wants. To be=20
perfectly honest, if your 2k logical blocks are not next to each other,=20
you shouldn't be issuing a 64k request. Or at least it should be broken up=
=20
before the vop_strategy() level.

As such, I don't think we need this support to do what you suggest. I can
think of other reasons I would like it, but the file system should only be
issuing requests (to this level of the kernel) that can make it to the
disk in contiguous blocks.

Take care,

Bill

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

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

iD8DBQFDs3gRWz+3JHUci9cRAq+yAJwPFpvl5r9TnuKWuBPp3cJJwHY/OQCZAVxU
drYRj5xoXeQ7Am7cEn5Z/jM=
=GgDV
-----END PGP SIGNATURE-----

--Md/poaVZ8hnGTzuv--