Subject: Re: Second patch for lseek() sparse file extension
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 09/21/2006 21:03:58
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,
> 2nd try that ought to be complete. I had to change the VOP_SEEK() a bit=
> since i was worried about FS layering and got wierd results at times; thu=
> 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=
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,


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

Version: GnuPG v1.4.3 (NetBSD)