On Tue, Oct 09, 2012 at 11:50:27PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:13:52PM +0200, Manuel Bouyer wrote:
> > There is still a reference to MAXPHYS in ufs_bmaparray(), which, if I got
> > it right, will limit the *runp in VOP_BMAP(), which will limit iobytes
> > in genfs_do_io().
> >
> > but that doens't explain why I see 32k xfers. And, to make things worse,
> > I see 64k if I start the big file read with debug enabled, so it looks
> > timing-dependant :(
>
> OK, after fixing the issue I created in ra_startio(), and replacing the
> MAXPHYS above with mnt_maxphys, I get:
> device read KB/t r/s time MB/s write KB/t w/s time MB/s
> wd0 504.22 129 0.90 63.45 0.00 0 0.90 0.00
>
> with a 'cat big_file > /dev/null'
> writes are still limited to 64k ...
I would hope that cat'ing a file to /dev/null wouldn't result in any writes.
:-)
I assume you meant 'cat big_file > other_file' ?
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;
}
there's a similar block in many file systems at this point. when I wrote that
I intended to replace it with something better before very long, but I just
never
got back to it, alas.
-Chuck
