Subject: Re: RFC: VOP_BMAP() change proposal
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 12/30/2005 10:45:43
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 30, 2005 at 03:22:34AM +0100, Reinoud Zandijk wrote:
> Dear folks,
> VOP_BMAP is currently defined as:
>      int
>      VOP_BMAP(struct vnode *vp, daddr_t bn, struct vnode **vpp,
>               daddr_t *bnp, int *runp);
> My problem with this is that it doesn't signal whether its a _read_ or a=
> _write_ request. Some filingsystems with a preference for shuffling block=
> like UDF and also LFS might want to rewrite blocks on a different place=
> than it reads them from. So when f.e. genfs() calls BMAP on an extent it=
> gets both a wrong mapping but most of all a wrong _runlength_. A fragment=
> file that is written out in a sequential part is thus splitted up in=20
> seperate sectors just because it was fragmented on the disc... :-S this=
> logic is baffling me.
> A simple solution would be to pass a flag to the BMAP indicating reading =
> writing so filingsystems that want to distinguish between the two can do=
> so.
> Thoughs?

I think you're trying to solve the problem the wrong way. You should not
schedule writes in VOP_BMAP(), thus you don't need to know if you're
mapping for write or read.

Do more what LFS does. It faces the exact same issues you are, and yet=20
it's fine with the existing VOP_BMAP(). :-)

Put another way, doing this in VOP_BMAP() is reactive. You should be=20
_proactively_ scheduling writes. If you do all of the scheduling in=20
VOP_BMAP(), you can only schedule the operation you are asked about. As=20
you note above, it's harder to consolidate. Also, you rely on genfs=20
scheudling the writes; if a buffer doesn't get requested for write, you=20
don't get to consolidate it with others.

Doing something higher up will let you have access to all the data for a=20
file, and let you manipulate the writes much better.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)