Date: Mon, 18 Apr 2011 21:47:50 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, Matthew D Fleming <mdf@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r220791 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys Message-ID: <20110418194750.GD3097@garage.freebsd.pl> In-Reply-To: <20110418192810.GX48734@deviant.kiev.zoral.com.ua> References: <201104181632.p3IGWM5v077720@svn.freebsd.org> <20110418192810.GX48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--OaZoDhBhXzo6bW1J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 18, 2011 at 10:28:10PM +0300, Kostik Belousov wrote:
> > + if (offset + len > vap->va_size) {
> > + VATTR_NULL(vap);
> > + vap->va_size =3D offset + len;
> > + error =3D VOP_SETATTR(vp, vap, td->td_ucred);
> > + if (error !=3D 0)
> > + goto out;
> > + }
> I still do not see a reason to do VOP_SETATTR() there. VOP_WRITE() will
> do auto-extend as needed. Also, see below.
Yeah, also when we extend file size we could skip reading zeros.
> > + if (offset < vap->va_size) {
[...]
> > + } else {
> > + bzero(buf, cur);
> > + }
> Wouldn't VOP_SETATTR() at the start of the function mostly prevent
> this bzero from executing ?
Once we drop the vnode lock, the file size can change under us, no?
> I estimated what it would take to do the optimized implementation for UFS,
> and I think that the following change would allow to lessen the code
> duplication much.
>=20
> What if the vnode lock drop and looping be handled by the syscall, instead
> of the vop implementation ? In other words, allow the VOP_ALLOCATE()
> to allocate less then requested, and return the allocated amount to
> the caller. The loop would be centralized then, freeing fs from doing
> the dance. Also, if fs considers that suitable, it would do a whole
> allocation in one run.
I'd still go with SEEK_DATA/SEEK_HOLE loop as I suggested on arch@.
If you would like to spend time on it, having SEEK_DATA/SEEK_HOLE
support in UFS would be beneficial for other purposes too.
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
--OaZoDhBhXzo6bW1J
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEARECAAYFAk2slWUACgkQForvXbEpPzQOEgCg15ceghLKdon8khGcub0z2pwg
3n8AnipfpoOnf6hpQ3nut1gvoRT/W+F6
=69mP
-----END PGP SIGNATURE-----
--OaZoDhBhXzo6bW1J--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110418194750.GD3097>