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

On Tue, Dec 23, 2003 at 07:09:53PM +0100, Juergen Hannken-Illjes wrote:
> On Tue, Dec 23, 2003 at 09:55:37AM -0800, Bill Studenmund wrote:
> > On Fri, Dec 19, 2003 at 10:13:22PM +0100, Juergen Hannken-Illjes wrote:
> > > How does VOP_BMAP() handle fragments?
> > >=20
> > > Given a file with holes obtained from ftruncate(), what does VOP_BMAP=
()
> > > return in its argument "bnp" if it finds a fragment?

Holes are usually a problem. VOP_BMAP() isn't good for triggering=20
allocation, which is what you need to fill a hole.

> > > Is it the block number of the fragment or will it return (daddr_t)-1?

It'll be the fragment's address.

> > > Is it always ok to write a full block to "bnp"?

If you mean ffs block, I don't think so. I think you have to know that you=
=20
won't be writing past the end of the file.

> > I think you've been bitten by an ffs ambiguity (since only ffs has=20
> > "fragments").
> >=20
> > What ffs calls a fragment in its documentation (the 1k in an 8k/1k file=
=20
> > system) is what the kernel internally calls a block. Since VOP_BMAP()=
=20
> > deals with kernel things, a "fragment" is a block, so there is no probl=
em.
>=20
> So ufs_bmaparray() first sets "maxrun =3D MAXPHYS / mp->mnt_stat.f_iosize=
 - 1"
> which is "64k / 8k - 1 =3D=3D 7" from example above. Then it computes "*r=
unp" as
> the number of 1k blocks (fragments) that are contiguous.
>=20
> >From sys/dev/vnd.c:
>=20
> 	bsize =3D vnd->sc_vp->v_mount->mnt_stat.f_iosize;
> 	...
> 	error =3D VOP_BMAP(vnd->sc_vp, bn / bsize, &vp, &nbn, &nra);
> 	...
> 	sz =3D (1 + nra) * bsize;
>=20
> This looks like it would run on "blocks" instead of "fragments".

Having a run size of ffs blocks does not mean that the block number=20
returned is also in units of ffs blocks.

ffs will read f_iosize blobs up until the end of the file, so it's=20
appropriate for sz to be in f_iosize blobs.

I've been quite confused by the code, so I'm not really sure if the bn /=20
bsize is right; it might really need to be bn / f_bsize (which is=20
"fragment" size.

Take care,

Bill

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

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

iD8DBQE/6Nn2Wz+3JHUci9cRAk0UAJ4qg17LxDJeqzq5EL5jMMD3ufDg7ACfbris
9nsJ3Sou0N1yqaK/JWL/zfo=
=X3Yo
-----END PGP SIGNATURE-----

--hHWLQfXTYDoKhP50--