From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Tue,  4 Oct 2011 15:05:56 +0200
User-Agent: KMail/1.13.6 (Linux/3.1.0-rc8-l40+; KDE/4.5.5; x86_64; ; )
References: <cae68b045335522b8d7bfbdf9260bb3b@hamnavoe.com>
	<201110041452.50242.dexen.devries@gmail.com>
In-Reply-To: <201110041452.50242.dexen.devries@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201110041505.56488.dexen.devries@gmail.com>
Subject: Re: [9fans] copying fossil filesystem to a bigger disk
Topicbox-Message-UUID: 31a69fc6-ead7-11e9-9d60-3106f5b1d025

On Tuesday 04 of October 2011 14:52:49 dexen deVries wrote:
> compare write bandwidth for 4096B data chunks at offset modulo 512B:
> (n*512B+k), where `n' is random. compare 8 runs, each with const `k' from=
 {
> 0, 1, ...7 }. sync after every write. write much more than drive cache
> size at each run (probably 64MB on modern HDs).


oops, was supposed to be (n+k) * 512B.

if you expect seek times to dominate, perhaps
for (..; ++n; ..) {
  write 4096B @ (n*8+k) * 512B; sync;
}
would be better -- that is; walk sequentially but sync in 4096B chunks=20
possibly across 4k sectors (when `k' mis-aligns).


=2D-=20
dexen deVries

[[[=E2=86=93][=E2=86=92]]]

http://xkcd.com/732/