svn commit: r220791 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Pawel Jakub Dawidek]

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 = offset + len;
> > +		error = VOP_SETATTR(vp, vap, td->td_ucred);
> > +		if (error != 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.
> 
> 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 at .
If you would like to spend time on it, having SEEK_DATA/SEEK_HOLE
support in UFS would be beneficial for other purposes too.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20110418/7c196d27/attachment-0001.pgp