Subject: Re: Second patch for lseek() sparse file extension
To: None <tech-kern@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/21/2006 21:03:58
Content-Type: text/plain; charset=us-ascii
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().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----