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@. 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
pgp1qSb3OEnrS.pgp
Description: PGP signature