On Sun, Nov 21, 2004 at 04:55:47PM +0100, Arjan van de Ven wrote: > > On Sun, Nov 21, 2004 at 10:42:45AM -0500, Alan Cox wrote: > > On Sat, Nov 20, 2004 at 11:50:49PM +0100, Ziga Mahkovec wrote: > > > This chart includes data from iostat (sysstat package). Notice how the > > > disk is fully utilized (%util) during readahead, but the throughput > > > (rkB/s) is *really* low. This could very well be a problem with my hard > > > disk. hdparm seems fine though (and I checked the parameters before > > > running readahead). > > > > Disks are very very seek constrained. You get wonderful performance reading > > linear data. The moment you read a lot of scattered files or a file with a > > lot of segments you will get low performance - even more so on laptops than > > desktops > > yeah we saw that; sorting the list on disk sector shaved 2 seconds off... > if we want to save more we'll have to fix the on disk layout to be less > spread out. That's not going to be fun... Let's see ... Suppose we isolate all the resources we need to load quickly, we have a list of files, hopefully all from the same / partition, while in single user mode and without concurrent activity: for foo in $list: cp $foo $foo.new for foo in $list: rm $foo for foo in $list: mv $foo.new $foo We could expect filesystems to allocate the new blocks (data and possibly metadata) more or less sequentially on disk. What would led the filesystem code to not be sequential (most of the time assuming a single block device underneath) ? Just wondering... Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
