From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <01387c9397134fc04134154232a11821@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] More venti sync woes.
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 27 Sep 2007 19:03:59 -0400
In-Reply-To: <509071940709271549l57a778e5k9d0f70e3d3a670be@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: c6350b1e-ead2-11e9-9d60-3106f5b1d025

> as for my venti config: i'll confirm when i get thin thing booted off
> another medium, but from memory: i've got a ~30GB fossil partition, a
> 64MB bloom filter, a 5-10GB index, and a ~120GB arenas partition.
> there's also a 9fat and swap in there somewhere. it's all on one disk.

> i certainly appreciate the fact that non-dma disks can be dog slow
> under load. but at this point, whatever it's doing it's been doing for
> over 24 hours; even a factor of 50 puts that at just under half an
> hour to reboot, which seems like an unreasonable amount of time for a
> server to spin on an unclean reboot. what was the rough improvement
> factor you observed?

generally, a sata disk is good for 30-50 MB/s using sequential
IDE dma transfers on the outer tracks.  /non-sequential access
can be as slow as non-dma access./

(i fixed a similar problem reciently with the on-disk cache of ken's fs.
throughput went up by a factor of 20 or so.)

russ would have to answer questions about disk access patterns with
venti, but you could be generating constant seeks between the various
partitions.

- erik