From owner-freebsd-current  Wed Mar 22  7:46: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ns0.netcraft.com (ns0.netcraft.com [195.188.192.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2076B37BD9A; Wed, 22 Mar 2000 07:45:56 -0800 (PST)
	(envelope-from richard@netcraft.com)
Received: (from richard@localhost)
          by ns0.netcraft.com (8.8.8/8.8.8) id PAA08760;
          Wed, 22 Mar 2000 15:44:20 GMT
          (envelope-from richard)
From: Richard Wendland <richard@netcraft.com>
Message-Id: <200003221544.PAA08760@ns0.netcraft.com>
Subject: Re: FreeBSD random I/O performance issues
In-Reply-To: <38D833BC.A082DF09@originative.co.uk> from Paul Richards at "Mar
 22, 2000 02:45:16 am"
To: Paul Richards <paul@originative.co.uk>
Date: Wed, 22 Mar 2000 15:44:20 +0000 (GMT)
Cc: Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > With sync it's ~20,000 operations matching the total of reads &
> > writes.  This demonstrates another aspect of the bug, sync behaviour
> > should cause 10,000 operations; the reads aren't being cached.
> 
> This isn't quite true. It's 20,000 *write* operations. I put this down
> to the mtime update for each write doubling the number of actual write
> operations. No read operations take place, the data *does* come out of
> the cache. There's nothing wrong with reading as far as I can tell.

Yes, you're absolutely right, I should have looked at my own data
more closely.

If I change the test program to call fsync after write, and run on
a default mount filesystem I also see 20,000 I/O operations from
10,000 writes.  This probably impacts more real programs out there
than sync mounts.

If this is mtime updates being does synchronously, that seems a
separate issue to the clustering/VM issue, and seems to me it should
be fixed.  It'll normally double the number of all writes won't
it, possibly forcing seeks between otherwise localised access.

Can anyone offer an alternative hypothesis to mtime updates being
done synchronously?

Looking at my logs for the sync filesystem test, mount output before
and after shows all ~20,000 operations are writes::

	mount
	/dev/wd0s2e on /var (local, synchronous, writes: sync 182 async 10)

	time ./seekreadwrite xxx 10000
	0.1u 7.8s 1:47.61 7.4% 5+179k 0+20000io 0pf+0w

	mount
	/dev/wd0s2e on /var (local, synchronous, writes: sync 20190 async 15)

But when using fsync on a default mount filesystems, 10000 writes
are sync and 10000 async:

	mount
	/dev/wd0s2e on /var (local, writes: sync 682 async 2764)

	time ./seekreadwrite xxx 10000
	0.0u 1.7s 0:54.34 3.3% 4+171k 0+20000io 0pf+0w

	mount
	/dev/wd0s2e on /var (local, writes: sync 10682 async 12777)

This is on the ATA machine that could run the test in 4 seconds
without fsync, 54 seconds with fsync, suggesting some head movements
may be being forced, though not 20000 as that would imply 2.7ms
per seek.

	Richard
-- 
Richard Wendland				richard@netcraft.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message