Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-07-29 15:24:15 +0200 \ Bernd Schubert: > On Thursday 29 July 2004 12:45, Lars Ellenberg wrote: > > / 2004-07-29 01:10:31 +0200 > > > > \ Bernd Schubert: > > > > can you post more verbose test results on some website, or here? > > > > which file system? > > > > > > The filesystem is reiserfs. > > > > btw, what did drbd report about its estimated > > syncer performance during initial full sync, or during any other sync? > > (grep for "drbd.: Resync done" in syslog) > > This seems to vary pretty strong: > > syslog.6:Jul 19 13:13:37 hamilton1 kernel: drbd0: Resync done (total 21 sec; 28867 K/sec) > syslog.6:Jul 19 13:13:42 hamilton1 kernel: drbd1: Resync done (total 25 sec; 5734 K/sec) > syslog.6:Jul 19 13:23:17 hamilton1 kernel: drbd2: Resync done (total 33 sec; 26686 K/sec) > syslog.6:Jul 19 13:31:38 hamilton1 kernel: drbd3: Resync done (total 37 sec; 22939 K/sec) > syslog.6:Jul 19 13:34:12 hamilton1 kernel: drbd4: Resync done (total 171 sec; 27792 K/sec) > > syslog.4:Jul 23 10:12:54 hamilton1 kernel: drbd0: Resync done (total 28 sec; 37595 K/sec) > syslog.4:Jul 23 10:13:22 hamilton1 kernel: drbd1: Resync done (total 56 sec; 18797 K/sec) > syslog.4:Jul 23 10:13:51 hamilton1 kernel: drbd2: Resync done (total 85 sec; 12384 K/sec) > syslog.4:Jul 23 10:14:01 hamilton1 kernel: drbd3: Resync done (total 93 sec; 3577 K/sec) > syslog.4:Jul 23 10:14:29 hamilton1 kernel: drbd4: Resync done (total 120 sec; 8772 K/sec) > > syslog.1:Jul 26 11:11:55 hamilton1 kernel: drbd3: Resync done (total 12 sec; 27722 K/sec) > syslog.1:Jul 26 11:12:11 hamilton1 kernel: drbd0: Resync done (total 33 sec; 31899 K/sec) > syslog.1:Jul 26 11:12:28 hamilton1 kernel: drbd4: Resync done (total 45 sec; 23392 K/sec) > syslog.1:Jul 26 11:12:41 hamilton1 kernel: drbd1: Resync done (total 61 sec; 16786 K/sec) > syslog.1:Jul 26 11:13:13 hamilton1 kernel: drbd2: Resync done (total 89 sec; 11827 K/sec) > > > Are you sure that these numbers are correct at all? When one looks at > /proc/drbd during a sync, I always think that only the numbers of average sync > for for the first sync device can be correct. > IMHO it seems to calculate the average sync rate for the other devices including > the the wait time and so gives smaller numbers thats right. we defined "average" as amount/(finish time - start time), ignoring any amount spent in paused state. but this indicates that you could expect ~30MB/sec minus fs and nfs overhead for linear writes. > > do you run iozone on some client on the nfs mount, > > or on the host itself on a direct mount? > > Those numbers came from the direct mount of course. If we would get those > number on the clients we certainly wouldn't complain ;) > > now, 2.4 only has *one* thread to flush *all* devices. > > 2.6. can basically flush all devices "in parallel" ... > > what backing storage device(s) did you use? > > Its one ide-to-scsi raid array. Hmm, when one only writes locally to > one of the drbd partitions there shoudn't be several flushd threads requires? > Or does flufhing to the network also count. no. but for software raid for example... thats why I ask. > > process scheduler latency as well as interrupt latency may have an > > impact (HZ value). io-scheduler may have an impact. > > maybe something has changed in the implementation of the network stack, > > or likely in the nfs implementation, also. > > What a pity that it still runs so unstable. :) Lars Ellenberg