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

On Thu, Sep 21, 2006 at 08:47:49PM +0200, Reinoud Zandijk wrote:
> Dear folks,
>=20
> 2nd try that ought to be complete. I had to change the VOP_SEEK() a bit=
=20
> since i was worried about FS layering and got wierd results at times; thu=
s=20
> i pass the vattr down so it reflects the top vnode and not the bottom=20
> vnode. This might be important for some file systems and it saves=20
> duplicating and thus error-prone ness.

No. Don't. Please look into the weird results, but you should NOT be=20
passing down the vattr. The file system doing the work should know this=20
information better than anything else.

I suggest that, before you check this in, you implement it for ffs (or lfs=
=20
or ext2fs). :-)

A file system that can actually see holes will ignore the vattr you pass=20
in; the seek op will need to lock out block allocation changes (as yamt=20
noted), and so by definition, any vattr previously obtained is stale.

For file systems that will be using genfs_seek(), let's throw a=20
VOP_GETATTR() (back) in there, and we perform the data/hole verification=20
with respect to the same atom at which we measured the attributes.

> If all is ok, i'd like to commit this.

I actually prefered the previous version w.r.t. VOP_GETATTR().

Take care,

Bill

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

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

iD8DBQFFE2CuWz+3JHUci9cRAthEAJ4+XRodHJG/iWhQtyGasTgIVQ6sbwCeOpDG
BallVu8qGbMbenoTMgQLIYI=
=D7LT
-----END PGP SIGNATURE-----

--AqsLC8rIMeq19msA--