On Wed, Oct 10, 2012 at 11:48:37AM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> >
> > if so, then the reason for the 64k writes would be this block of code in
> > ffs_write():
> >
> > if (!async && oldoff >> 16 != uio->uio_offset >> 16) {
> > mutex_enter(vp->v_interlock);
> > error = VOP_PUTPAGES(vp, (oldoff >> 16) << 16,
> > (uio->uio_offset >> 16) << 16,
> > PGO_CLEANIT | PGO_JOURNALLOCKED | PGO_LAZY);
> > if (error)
> > break;
> > }
>
> Upon reflection, I do not understand how this works.
>
> Consider a write() of 131072 starting at file offset 0.
>
> oldoff >> 16 will be 0; uio->uio_offset will be 131072, unless
> this is the source of my misunderstanding, after the call to ubc_uiomove().
> Otherwise, I don't see how uio->uio_offset gets updated at all.
>
> Now, we VOP_PUTPAGES(vp, 0, (131072 >> 16) << 16)) which is of course
> VOP_PUTPAGES(vp, 0, 131072). So why does this only push out 64K?
I don't think you can have oldoff at 0 and uio->uio_offset at 131072,
because the write is split in smaller chunks by the
while (uio->uio_resid > 0) { } loop. The chunk size will be:
bytelen = MIN(fs->fs_bsize - blkoffset, uio->uio_resid);
so we get data from userland in at most fs->fs_bsize chunks at a time,
and when we cross a 64k boundary we start a write.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
