Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: [tls-maxphys] src/sys/dev



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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index